scope of SIA schema

[Ray Plante]

Hey Markus,


On Mon, 29 Mar 2004, Markus Dolensky wrote:
> What's the scope of the SIA schema definition http://www.ivoa.net/xml/SIA/ ?
> 
> I simply assume that you were involved producing it and therefore my question 
> to you:
> 
> In which context should it be used?
> - When encoding SIA query mode response?
> - As response to a registry query?

I'm glad you noticed this, and I'm happy to advise as necessary for SSA.  

That SIA schema is specifically for describing SIA services within the 
registry.  It is an extension of the VOResource schema specific for SIA.  
Since SIA responds with a VOTable, it is not intended to be part of the 
SIA query response.  

The idea is that every standard service will have a set of metadata for 
describing the capabilities of an implementation which are specific for 
that type of service.  For SIA, this metadata is described in concept in 
section 7.2 ("Registering a Compliant Service").  SSA will have its own 
set (though may be very similar to SIA) which should be similarly 
described in the SSA spec.  The VOResource schema has a special element 
for including this specialized metadata called "Capabilities".  The SIA 
schema extends this element to add the SIA metadata; as part of this 
extension this element is "renamed" to "SimpleImageAccess" (in XML-speak, 
it is defined as being in the same substitution group).  

For an example see 
http://nvo.ncsa.uiuc.edu/cgi-bin/nvo/oai.pl?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo%3A%2F%2Fadil.ncsa%2Ftargeted%2FSIA
This is the SIA service to the ADIL (wrapped in an OAI envelope--just look 
for the VOResource element; within that, find the SimpleImageAccess 
element for SIA-specific info).

> And, how about extending it to work also with SSA? The number of additional 
> elements should be marginal.

I think at this stage, you should approach this by defining a "new" set of 
metadata that will be very similiar to SIA.  Reuse the same names where 
the concepts are the same.  I would defer linking the two sets of metadata 
in a formal way to a time when the two services are formally connected at 
the protocol level (e.g. "SDA").  In practical terms, this would mean 
creating an SSA extension schema with a different namespace as SIA's; 
although much of the definition can be cut-and-pasted in from SIA.  

> The SIA query mode (and presumably SSA query mode) returns a VOTable that 
> requires special client software to parse it. The question is whether we can 
> avoid this in future by re-using things like the VOResource in the SIA/SSA 
> query mode context. It seems, however, that the given SIA schema is 
> weaving in what I would call registry-type components (VOResource, 
> VODataService) PLUS SIA specific elements. The presence of the Schema 
> suggests that SIA servers and clients need to support all of it(?)

As you may now understand, VOResource and its SIA extension was not 
designed to encode SIA query responses.  They are about describing the 
service itself and helping applications to use it intelligently.  (Thus, 
your assessment of the "weaving in" is absolutely correct!)  Since, an SIA 
query response is essentially a table, using VOTable seems a good choice 
for this.

I hope this helps.  Let me know if you have more questions.

cheers,
Ray