SSA validator
Pierre Le Sidaner
pierre.lesidaner at obspm.fr
Mon Jan 28 09:04:20 PST 2013
So I decide to update properly the SSA validator to be as compliant as
possible with SSA 1.1
http://voparis-validator.obspm.fr/
Then I decide to make correction proposition on the wiki page for
defining validation test
http://wiki.ivoa.net/twiki/bin/view/IVOA/SSAValidaterTests
comment on my propositions are welcome.
SO I decide to compare my validators to Defining Validation Tests, it
seem that all theses pages are not following properly all constraint of
the standards
I don't know if it's my job to correct them, I just wait for your first
comment on SSA
Regards
Pierre
On 01/25/2013 05:36 PM, Douglas Tody wrote:
> 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
>>
>> --------------------------------------------------------------------------
>>
>>
--
-------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the dal
mailing list