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
>