Comments on V1.1 - incl 'what about a unit schema?'

[Andreas Wicenec]

Dear all,

this is an interesting thread and I have to say that in general I agree 
with what Martin and David stated. VOTable while useful as it is right 
now should not be seen as much more as just one way to represent a 
tabular data model. Since a lot of parties agreed on being able to 
handle it it gets more valuable, but I also agree that VOTable has a 
couple of major shortcomings when it comes to comply to XML standards 
or just habits. Now I think that most of this we can actually overcome 
by simply using something more appropriate in places where it is 
necessary and use stylesheets to convert to plain VOTable when we have 
to talk to VO services. This is also we we are planning for ALMA, where 
we had to divert from plain VOTable already, because the data to be 
described is more complex than what VOTable allows for the time being.

Happy Easter,
Andreas


On 08.04.2004, at 19:07, Martin Hill wrote:

> On Thursday 08 April 2004 12:50 pm, Francois Ochsenbein wrote:
>
>>>   * re 3.5: LINK
>>>     in what way are parsers expected to 'understand' the 'three 
>>> common
>>>     protocols'? What is the parser expected to do with the object at 
>>> the
>>>     end of the link? Eg, does it embed the data in the element being
>>>     parsed, shell out to a browser etc?
>>
>>   The parser does not do any action -- that's the role of the 
>> application.
>>   But the parser has to retrieve this links so that the application
>> software is able to retrieve the linked data.
>
> The difference between parser and application here is blurred if the 
> parser
> is anything other than the standard java parser implementations. At 
> this
> level we should be describing what goes into the link, it is then up 
> to the
> parser/application implementation to handle it.
>
>>>   * re 4.3: unit
>>>     are the unit values enumerated under some schema? how are they
>>>     validated?
>>
>>   Full references are given. There is java (or C) code which can make
>>   this test. Too complex for XSD, the number of possible combinations
>>   can be huge.
>
> I agree that the units should not go into the *VOTable* schema, but I 
> am
> beginning to think we could do with defining a Units schema (probably 
> based
> on the CDS list at http://vizier.u-strasbg.fr/cgi-bin/Unit?%3f).  This 
> would
> enumerate all standard units and a way of including specials, and then 
> this
> schema can be 'imported' to the VOTable schema.  I don't suggest this 
> for
> v1.1, but as a separate bit of work for us to include in v1.1.1 (or 
> 1.2, or
> whatever the current versioning sequence is!)
>
>>>   * re 4.6: MIN/MAX & OPTION
>>>     is it valid to have both MIN/MAX and OPTION? Schema allows both.
>>
>>   I agree, it looks strange to have MIN MAX and OPTION -- how would
>>   this restriction be written in XSD ?
>
> I think there is a clever way of doing it, but a more explicit
> straightforward way is just to use a wrapping element around MIN/MAX 
> and use
> choice, ie:
>
> <xs:choice maxOccurs="1">
>  <xs:element name="Option" type="xs:string"/>
>  <xs:element name="Range">
>    <xs:complexType>
>      <xs:sequence>
>        <xs:element name="Min" maxOccurs="1" minOccurs="1"  
> type="xs:string"/>
>        <xs:element name="Max" maxOccurs="1" minOccurs="1" 
> type="xs:string"/>
>      </xs:sequence>
>    </xs:complexType>
>  </xs:element>
> </xs:choice>
>
> Cheers,
>
> Martin
>
> -- 
> Martin Hill
> Astrogrid/AVO, ROE
> Tel: 07901 55 24 66