1  Erratum Content

The definition of dataModel/@ivo-id in the schema that accompanies the original REC-1.0 submission of TAPRegExt

(Demleitner et al., 2012) is erroneous. Like all other ivo-id attributes in TAPRegExt, its type should have been xs:anyURI (instead of vr:IdentifierURI, as originally defined). The text starting with "This is fine" and ending with ïn the schema for this attribute" in section 2.3 is wrong in the light of current Registry Working Group recommendations and should be considered removed.

With this Erratum, http://www.ivoa.net/xml/TAPRegExt/TAPRegExt-v1.0.xsd is updated, such that vr:IdentifierURI in line 160 now reads xs:anyURI. Clients using local or otherwise cached copies of the schema are advised to update to avoid flagging now correct documents as invalid. No currently valid documents will become invalid with this change.

2  Rationale

dataModel/@ivo-id was originally considered an unversioned reference to a StandardsRegExt record. The Registry Working Group now recommends standards to have IVORNs like

ivo://ivoa.net/std/stdname#item−1.0,

i.e., what is referenced actually is a (versioned) entity within a StandardsRegExt record rather than the record itself.

vr:IdentifierURI does not admit fragment identifiers, which is one reason why all remaining ivo-id attributes in TAPRegExt have been defined as xs:anyURI.

By now, the special role of dataModel/@ivo-id versus the other ivo-id attributes - in conflict with current Registry recommendations - is more than a mere inconvenience, as standards like RegTAP need to use new-style standard identifiers. To allow this without making both registry records and capability documents invalid, the schema must be corrected. As we believe the impact on existing clients and practices is zero, we suggest a silent schema update.

The alternative, a change of the schema's target name space, on the other hand, will certainly break existing clients unless they daringly opted to ignore the namespace of the elements.

3  Impact Assessment

All existing valid capability records remain valid, as the domain of xs:anyURI is a superset of the domain of vr:IdentifierURI. It is conceivable that existing clients validating against a built-in copy of the TAPRegExt schema or parsing using a generated validating parser might reject capability records with the new generalized data model identifiers. It seems highly unlikely, though, that such implementations have actually been made.

Any functionality provided through non-validating parsers or validating parsers using the IVOA-provided (or document-provided) schema is not concerned. In particular, as comparison of data model identifiers takes place character-by-character (ignoring case), even legacy clients will be able to work with the new generalized data model identifiers.