Comments on the new Schemas

[Ray Plante]

Hey Aurelien,

These all look good, and I'm basically in agreement.  I'll report back 
once I've actually attempted to fix these.  

A few comments...

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.

> - We should rename OAIHTTPGet to just OAIHTTP, since the OAI doc forces 
> implementations to support both GET and POST. 

You are absolutely right--I had forgotten about this.  I would go with 
your OAIHTTP suggestion. 

> - StandardSTC might better be declared in the VOStandard schema, but I'm 
> not sure I understand how to use it. Also, I didn't fully read the 
> VOStandard file as I think we should concentrate on this schema after 
> the RI and the basic ones are in v1.0

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.)  

I just noticed that my stc.xml example is missing the meat of the 
description.  

> - I noticed that the only difference between DataService, CatalogService 
> and TableService are the Coverage and Table elements. Those two elements 
> are optional and I think we could put them both in DataService and get 
> rid of the two other extensions. 

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).

thanks!
Ray