SSA validator

[Douglas Tody]

On Fri, 25 Jan 2013, Pierre Le Sidaner wrote:

> On 01/25/2013 02:44 PM, Douglas Tody wrote:
>> On Fri, 25 Jan 2013, Pierre Le Sidaner wrote:
>> 
>>> I am currently updating my SSA validator at VOParis. Looking at this link
>>> 
>>> http://wiki.ivoa.net/twiki/bin/view/IVOA/ServiceValidation
>>> 
>>> I see that *4.2.5* The RESOURCE containing the results of a response to a 
>>> valid query must include one FIELD / PARAM element with: UCD mandatory
>>> In the SSA document 1.1 and older only Utypes are mandatory not UCD
>>> even in the SSA document 1.1   on  4.2.1
>>> UTYPEs of standard fields are required for identification of interface 
>>> elements and *must* be given and *must* comply with the SSA protocol (this 
>>> document) /.../ UCDs *should* also be given when specified by the protocol
>>> So do you want me to ignore the document Service Validator and validate 
>>> what is in the protocol document 
>>> http://www.ivoa.net/Documents/SSA/20120210/REC-SSA-1.1-20120210.htm
>> 
>> SSA uses UTypes to identify data model fields (that is what they are
>> for), however a special case is the flux or spectral axis coord type
>> which would be identified with a UCD.  Flux type for example is a
>> physical quantity not a data model field hence UCD is used.  The data
>> model field used to identify the flux type does have a UType, i.e.
>> Char.FluxAxis.Ucd.
>> 
>> Anyway I thought this was still merely a REC, at least in the SSA query
>> response.  Where in the spec does it say that this is mandatory?
> for Utype
> in 4.2.5 Access Metadata
> it's clearly said that utype parameters are mandatory, and you have a table 
> of what is mandatory
>
> in
> 4.2.1 Query Response Metadata
> Names of fields and parameters are left to the service provider. UTYPEs of 
> standard fields are required for identification of interface elements and 
> must be given and must comply with the SSA protocol

Right, the Utypes are required to identify interface elements and UCDs
are merely recommended since they are not normally required to use the
interface (except for things like flux type and that is really only for
analysis not discovery).  But from your original comment I got the
impression that you found UCDs were mandated someplace?  If so I just
wanted to clarify whatever the issue is.

>>> Moreover I as I have insist many time that XML schema referenced should 
>>> really be accessible to see if it's compliant with the text
>>> xmlns:ssa="http://www.ivoa.net/xml/DalSsap/v1.0" is not available
>> 
>> The xmlns usage in data models currently is not actually used as a
>> schema.  A data model is an abstraction, not an XML document (except
>> maybe for an XML serialization of an instance), hence cannot be defined
>> by an XML schema.  What we really need is a formal data model
>> definition, which is a topic for another discussion.  Meanwhile it
>> should not be an error of the xmlns is not pointing to a real document.
>> The string still identifies the data model used and its version. It was
>> put in essentially as a placeholder until we have a better mechanism for
>> this (just happens to be taking a while :-) ).

> So Doug you mean that xmlns: blabla is just a fake url to say that it's like 
> if we have a real xml serialization
> The real interest of it is to validate schema according to what is written, 
> it does not seem to me as a feature
> Moreover it writing serialisation is also a way to discover that model have 
> some "misfeature" and can be corrected

Since there currently is no actual SSA schema the validator should not
complain that one is not found.  What to do about the larger issue is
a topic to take up elsewhere.

> But it does not tell me what to do ?
> from start I will take Utype as mandatory and Ucd, type as a should 
> (warning), tell me if I do wrong
> happy to read you

Yes this is right, the Utypes are mandatory to identify fields of the
DM, the UCDs are merely recommended (should but not must provide - some
fields don't even have UCDs defined).

This looks like a great validator by the way, the most comprehensive I
have seen so far.

 	- Doug


> regards
> Pierre
>
>>
>>     - Doug
>> 
>> 
>>> regards
>>> Pierre
>>> 
>>> -- 
>>> -------------------------------------------------------------------------
>>>                           Pierre Le Sidaner
>>>                        Observatoire de Paris
>>> 
>>> Division Informatique de l'Observatoire
>>> Observatoire Virtuel 01 40 51 20 89
>>> 61, avenue de l'Observatoire 75014 Paris
>>> 
>>> mailto:pierre.lesidaner at obspm.fr
>>> http://vo-web.obspm.fr
>>> 
>>> -------------------------------------------------------------------------- 
>>> 
>
>
> -- 
> -------------------------------------------------------------------------
>                           Pierre Le Sidaner
>                        Observatoire de Paris
>
> Division Informatique de l'Observatoire
> Observatoire Virtuel 01 40 51 20 89
> 61, avenue de l'Observatoire 75014 Paris
>
> mailto:pierre.lesidaner at obspm.fr
> http://vo-web.obspm.fr
>
> --------------------------------------------------------------------------
>