I have said some of this in private emails - but I am resummarizing
for the list
On 14.12.2006, at 20:27, Arnold Rots wrote:
> Let's assume, for the sake of argument, that we are using ID/IDREF
> pairs, though that is not essential (as I said before, the issue is
> that the association needs to be unambiguous, not what the particular
> datatype is).
The problem *only* arises because the <AstroCoordSystem> id attribute and the <AstroCoordArea> coord_system_id attribute are of ID and IDREF type - it is because the XML parser requires global uniqueness of IDs in a document and that IDREFs point to IDs that there is a problem with the XML validity of a harvest document, because each VOResource record was using "human readable" IDs -e.g. UTC-FK5-TOPO that are fine if each VOResource is a document on its own, but become a problem for a harvest document of many such VOResource elements. However, if these two attributes were typed as strings then the XML parser would not try to enforce the uniqueness and referential constraints - it would be up to an external system to ensure the "STC validity" of a document.
Having the id and coord_system_id attributes as ID/IDREF does not anyway guarantee the "STC validity" of a document anyway as all that the XML parser checks is that the IDREF points at an ID somewhere globally in the document - there is no guarantee that the coord_system_id actually points at the id attribute of an AstroCoordSystem - it can point to *any* id type - so the following document is xml valid, but is obviously nonsense STC as all of the IDREFs point at the ObsDataLocation id.
<?xml version="1.0" encoding="UTF-8"?>
<p:ObsDataLocation id="idvalue0" idref="idvalue0" ucd=""
xmlns:p="http://www.ivoa.net/xml/STC/stc-v1.30.xsd"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance">
<p:ObservatoryLocation id="idvalue1"> <p:AstroCoordSystem id="idvalue3"></p:AstroCoordSystem> <p:AstroCoords coord_system_id="idvalue0"></p:AstroCoords> </p:ObservatoryLocation> <p:ObservationLocation id="idvalue2" idref="idvalue0" > </p:ObservationLocation>
I had earlier argued for using the xs:unique and xs:keyref schema constructs to be used which could potentially be used to define the exact scope of these references, but that would require some thought as the scope always has to be within one of the global elements of STC, which might end up restricting the use of STC itself in other schema - in short, this is not a quick solution, but would require careful consideration.
In conclusion *not* using ID/IDREF (and making the attributes xs:string or xs:anyURI) is IMHO the quickest and simplest solution to the immediate problem - it allows all current uses to STC still to work, allows the registry harvest document to be valid (with no changes) and gives breathing space to come up with a referencing scheme that is not directly checked by the XML parser, but by a yet to be written STC validator.
Paul Harrison
ESO Garching
www.eso.org
Received on 2006-12-15Z09:50:53