STC in VOResource records

[Arnold Rots]

Aurelien,

To repeat what I said a while ago:
This problem with STC is only one instance of a general issue.
We need a mechanism that allows associations to be specified in XML
documents and that does not break when documents or fragments of
documents are concatenated in new documents.
Dropping the use of ID/IDREF in STC solves this particular instance,
but does not address the general issue.  We need to more universal
solution.

  - Arnold

Aurelien Stebe wrote:
> Hi Ray and all,
> 
> I've been reading comments on this issue and trying to find a solution, 
> without much success I must say.
> I just wanted to state that I would prefer to avoid that solution 
> (though it is the best we have yet), because it breaks the separation 
> between what the Registry understands and what it must return. In other 
> words, a Registry could not anymore re-publish resources that it 
> harvested without understanding the "coverage" element, which is what we 
> agreed in Victoria.
> 
> I mean that in a first version we (at ESAVO) didn't plan on supporting 
> the "coverage" element, and with this solution we would have to add 
> logic on it to publish eventual Resources that have one. What would 
> happen if a non-official extension to the schemas use "id/idref" like STC ?
> 
> For me the best solution is to drop the use of "id/idref" in STC or find 
> a way for it not to impose modifications on other systems. I'm not an 
> expert on STC, so I'm not sure how for the moment, but I'm trying to 
> have a look.
> 
> Cheers and happy new year,
> Aurelien
> 
> Ray Plante wrote:
> > On Wed, 3 Jan 2007, Arnold Rots wrote:
> >> Hm, if I read the definition of xs:ID correctly, even slashes and
> >> colons are not allowed.
> >
> > Dang it--you are correct.  (Arnold, wouldn't want to save me from this 
> > hell? ;-)
> >
> > Okay--here's a revised ruling--please find any remaining mistakes!
> > For reference, the problem being addressed is summarized in
> > http://www.ivoa.net/forum/registry/0612/1764.htm.
> >
> > A publishing registry shall be responsible for creating IDs within STC
> > descriptions which are globally unique.  The convention for doing this
> > will be to use an ID of the following form:
> >
> >     <resource's authority id>_<resource's resource key>_<coordsys key>
> >
> > where all slashes are substituted with dashes (-) or underscores (_). 
> > For example, if the resource being described has an IVOA id of
> > "ivo://adil.ncsa/adil", then the following can be used as an internal STC
> > id refering to the UTC-FK5-TOPO standard system:
> >
> >     adil.ncsa_adil_UTC-FK5-TOPO
> >
> ================================================================================================
> This message and any attachments are intended for the use of the addressee or addressees only. The
> unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
> is prohibited. If you received this message in error, please delete it from your system and notify
> the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
> for any e-mail if modified.
> =================================================================================================
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------