Jumps: reg-dm mail archive :: IvoaResReg :: RegistryInterface :: VOResourceV10 :: RegUpgradeToV10
Meetings: InterOpMay2006ResReg :: InterOpSep2006ResReg

Summary of Registry Issues Discussed at the May 2007 InterOp

During the Registry sessions, we took a census of the assembly regarding a number of proposals. This page summarizes the proposals and reports the consensus of the group in attendence. Since a number of active working group meetings couldn't be at the meeting, we want to give folks an additional opportunity to offer comments and register their preferences before we take any decisions as final.

Please review these items and add any comments you have, preferably by 8 June.

Note: Page under construction

Minor RI standard issues

1. VOResource root element in harvesting Identify response

Problem
The RI spec requires that the element enclosing VOResource records returned through the search interface and the harvesting ListRecords operation to be <ri:Resource>. The VOResource record returned via the harvesting Identify operation does not have this restriction (RI section 3.1.5).
Proposal
Add same requirement on the VOResource root element to RI section 3.1.5.
Consensus of attendees
YES
Additional Comments

add your comments here

2. Should record requirements apply to deleted records

Problem
There are records that have been created in error but which have propogated to other registries; thus, they have been marked as deleted. Often such records will be end up being non-compliant as a VOResource record; making it compliant would require editing the record (on behalf of the publisher). Should we relax the compliance requirements for records marked deleted, or allow registry providers to edit the records appropriately?
Question
Should record requirements apply to deleted records?
Consensus of attendees
YES. Registry curators can add place-holding values as needed so that they validate.
Additional Comments

add your comments here

3. Require the use of xsi:schemaLocation in harvesting interface

Problem
The use of xsi:schemaLocation is required in response through the search interface; however, that same requirement is not in the harvesting interface.
Proposal
Make the use of xsi:schemaLocation required in the harvesting interface in the same way as in the search interface.
Consensus of attendees
YES.
Additional Comments

add your comments here

4. Require use of namespace prefixes in xsi:type values

Problem
Whether you are using the ADQL search method or XQuery, it is somewhat difficult to do precise matching on xsi:type values unless the use of namespace prefixes are required. Consider two possible values, xsi:type='vr:Service' and xsi:type='vs:DataService'. To match either in an ADQL search, you can provide the constraint, xsi:type like '%Service'. To match only the generic service, you could say xsi:type like '%:Service' but only if you could be certain that a prefix will always be used. In XML Schema, the prefix is not required if the type is from the default namespace.
Proposal
Require the use of namespace prefixes in xsi:type values.
Concensus of attendees
TABLED. While it was recognized that this presented a problem for clients, it was not clear whether this would be easy to control by registry implementations. Prefixes are often handled automatically by the XML processing tools, and it's not clear that explicit control would always be possible.

Additional Comments

If we do not reach any concensus on this, I think we should put it in only as a recommendation, but not a requirement.

-- RayPlante - 24 May 2007

add your comments here

5. Location of namespace declarations

Problem
Cutting out VOResource records out of a Harvesting response can be a little tricky because one has to make sure all the namespace declarations are captured. Particularly tricky is the appearance of a prefix within an xsi:type= attribute value, because most XML parsers tend to ignore the prefix, treating the whole value as an opaque string. If we required that all namespace declarations used by the VOResource record appear within the VOResource portion of the OAI response (and not in the OAI envelope), it would be possible to lexically (i.e. not using an XML parser) to cut out the VOResource record at the start and end of the <ri:Resource> element.
Proposal
Require that all namespace declarations used by the VOResource record appear within the VOResource portion of the OAI response.
Consensus of attendees
NO. Like in (3) above, namespace declarations are often controled transparently by XML tools, and so it might be hard to control where they get placed.
Additional Comments

add your comments here

Missing Agreements

I noticed that we neglected to integrate several agreements from the Victoria meeting into our standards, so we will need to do this.

6. Searchability of core VOResource metadata

Problem
It was AGREED in Victoria that all searchable registries must support constraint-based searching against, at a minimum, all of the metadata terms in the VOResource schema.
Proposal
Update RI to reflect this agreement.
Consensus of attendees
YES.
Additional Comments

add your comments here

7. Returning full VOResource records

Problem
It was AGREED in Victoria that a registry must return the full VOResource record as it was originally constructed or as harvested from another registry. RI does not specify this. As a way to deal with the graininess issue, we thought that this requirement should be relaxed a bit, so as to allow extra fine grained information obtained by a means other than harvesting (e.g. directly from the service) to be returned to end users via the search interface.
Proposal
Add requirement to RI that the original VOResource record must be returned in its original state via the harvesting interface; however, a registry may add additional information in the VOResource records returned via the search interface.
Consensus of attendees
YES.
Additional Comments

add your comments here

under construction


Edit | Attach | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2007-05-24 - RayPlante
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback