Comments on the new Schemas

[Aurelien Stebe]

Hi all,

I reviewed the schemas and here are a few comments :

- The "validatedBy" attribute on ValidationLevel should be made 
"required", because a level number without any indication about who 
validated it is not very useful ... or do we assume it is the 
queried/managing registry if empty ?

- The "managedAuthority" element should have minOccurs="1", since a 
registry must manage at least its own AuthorityID.

- The "validationLevel" is missing in "RegCapRestriction" (VORegistry.xsd)

- We should rename OAIHTTPGet to just OAIHTTP, since the OAI doc forces 
implementations to support both GET and POST. If we make it also an 
extension of "ParamHTTP", because it is a ParamHTTP protocol, we can use 
the QueryType to specify GET or POST or both. I assume that in 
ParamHTTP, if the QueryType element is missing the endpoint supports 
both GET and POST, or should we add the BOTH possibility to the list ? 
Note also that the RI doc refers all the time to "OAI GET". It should be 
replaced by just "OAI".

- In the Registry extension, the first documentation paragraph should 
say : A registry is considered a publishing registry if it contains a 
capability element with xsi:type="vg:Harvest". It is considered a 
searchable registry if it contains a capability element with 
xsi:type="vg:Search".

- 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

- Inconsistencies with "whiteSpace collapse" : it is missing on some 
elements. Here are a few examples : it should be on "AccessURL" element 
and not on its attribute "use"   /   "wsdlURL" should be of type 
"PaddedURI"   /   "AuthorityID is missing the "whiteSpace collapse"   
/   missing in the whole SIA and CS schemas.

- 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. Those three types are just confusing 
users. A service for which coverage is irrelevant would simply not have 
this element, and one without "tables" would not declare any.


Cheers,
Aurelien