Re: Comments on the new Schemas

From: Aurelien Stebe <Aurelien.Stebe-at-sciops.esa.int>
Date: Tue, 20 Jun 2006 16:28:52 +0200


Hi Ray,

Ray Plante wrote:
> On Fri, 16 Jun 2006, Aurelien Stebe wrote:
>
>> - The "managedAuthority" element should have minOccurs="1", since a
>> registry must manage at least its own AuthorityID.
>>
>
> Well, not actually. It is possible to be a searchable registry without
> being a publishing registry. Such a registry would have to register
> itself with another (publishing) registry; that publishing registry, then,
> would manage the authority ID.
>
>

Good catch there, I didn't think of that particular case. I wrote too fast. :)

> Registering StandardSTC will greatly abbreviate our STC descriptions and
> ease their handling: it allows us to describe the coordinate frame by an
> identifier rather than an explicit description. This is independent of
> whether or how we might register standard protocols. (In particular,
> we're not planning to put them in the RofR; rather Arnold Rots will manage
> them in a registry of his choosing.)
>
>

Agreed. I would propose to publish a version of VODataService without the STC, when we think the schema is stable enough. We could call it "v0.11" or "v1.0a" or something else. This schema wouldn't make it to Rec obviously, but would be useful as a reference until STC is fully tested and ready.

> As the VOResource spec document tries to explain, these types carry
> semantic meaning that is distinct and useful even if they do not extend
> the metadata beyond their parent. That is, it would be useful to query
> for CatalogServices distinct from a DataService, even if the description
> of the catalog is not included in the record.
>
> I had hoped that the new names are more meaningful (and therefore less
> confusing) to users. I'm okay with dropping TableService as we don't
> currently have any obvious services in this catagory (that I am aware of).
>
>

Not being an astronomer, I can't be sure if users need to query on this specifically or not. Obviously, if users need it and make the distinction when registering resources, let's keep it that way.

Cheers,
Aurelien Received on 2006-06-20Z19:43:53