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

RI and VOResource standards issues

1. RI: 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. RI: 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. RI: 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. RI: 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. RI: 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

under construction