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