Referencing STC in VOTable: IDREF problem
francois at vizir.u-strasbg.fr
Tue Oct 14 07:55:02 PDT 2008
Thank you a lot for your remarks (a carefull reading by new eyes
is always useful). Of course I fully agree with the "good practices"
asessment -- I did use a simple validator (XSV) but apparently this
one does not really care about the ID/IDREF rule...
I see essentially 2 (easy?) solutions which could work:
1. Use Arnold's proposed way with
as it is used in VOEvent; it requires an additional
namespace (and is not always understood by validators)
2. Specify the frame in a parameter with
The alternatives would look like:
1. xlink usage:
<GROUP ID="Coo1" utype="stc:AstroCoords"
<!-- etc -->
in the first example,
2. Specification via the "coord_sys_id" of the STC schema:
<GROUP ID="Coo1" utype="stc:AstroCoords">
<PARAM name="cooframe" datatype="char" arraysize="*"
<!-- etc -->
Although I would prefer the 2nd alternative (full compatibility with
the VOTable schema without additional namespaces), I'm open to
>On Tue, 16 Sep 2008, Francois Ochsenbein wrote:
>> 1. http://www.ivoa.net/internal/IVOA/IvoaVOTable/note_stc_v0.8.pdf
>> proposed note on "Referencing STC in VOTable"
>there is a problem with the scheme outlined in this Note.
>Section 4 says that the ref attribute of the second required GROUP
>element may reference an STC 'library' coordsys by using an
>identifier along the lines "ivo://STClib/CoordSys".
>This practice is exemplified in the Example in section 5.1:
> <GROUP ID="Coo1" utype="stc:AstroCoords"
>However, since the GROUP element's ref attribute is defined in the
>VOTable 1.2 schema with a type of "xs:IDREF" it is syntactically
>restricted in what characters it can contain: in particular non-XML-name
>characters such as "/" are illegal here. Hence this example cannot
>be valid against the VOTable 1.2 schema.
>Even apart from the syntactical issue, I don't *think* that the ID/IDREF
>mechanism can perform crossreferencing between different documents,
>here the VOTable instance and the STC library, which is what appears
>to be intended here, though it may be that my understanding
>of that issue is wrong (can anyone else confirm/deny?)
>The exact same problem afflicts the example in section 3.1 of the
>VOTable 1.2 document draft.
>A rethink is required. One possibility would be to keep the same
>general idea of referencing STC library documents, but to make it
>informal rather than enforced by the ID/IDREF mechanism.
>I recall however that Arnold was not keen on this approach when a
>similar solution was suggested to the problems arising from
>concatenating STC documents a year or two ago.
>I have two more general comments:
> 1. I would consider it good practice when writing a document such
> as this to validate any examples quoted against the schema prior
> to publication. As well as the issue above, there are a number
> of other errors in the first example of the Note which validation,
> and in some cases even XML parsing, would have picked up
> (stray </FIELD> close tag, missing IDs for the 'second referencing'
> refs). I haven't checked the other examples.
> 2. The approach outlined by this Note is quite complicated, though
> perhaps that is unavoidable given the job it is trying to do.
> Even assuming the problem I have identified above will be fixed,
> I am not therefore very hopeful about seeing applications capable
> of making sense of VOTables containing coordinate data in this form.
> I would of course be quite happy to be proved wrong about that.
>Mark Taylor Astronomical Programmer Physics, Bristol University, UK
>m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 32
More information about the votable