INFO tag

[Francois Ochsenbein]

To: votable at ivoa.net
cc: 
Reply-To: francois at astro.u-strasbg.fr
Subject: Re: <INFO> tag in VOTable1.2 
In-reply-to: Your message of Wed, 4 Mar 2009 15:40:02 +0000 (GMT) .
----------- (http://cdsweb.u-strasbg.fr/CDS.html)

>
>Francois,
>
>On Wed, 4 Mar 2009, Francois Ochsenbein wrote:
>
>> About the <INFO> tag -- if you expect possibility of adding
>> sub-elements (i.e. <INFO> may become a structure having
>> for instance a LINK possibility, or even introduce
>> a fully new sub-element) this is impossible with the
>> VOTable1.1 definition: limiting the contents of INFO
>> to just text locks the tag (you can't have text and
>> sub-elements within a single XML element).
>
>? I don't understand that.  You certainly can have text and
>sub-elements within a single XML element.

==> Oh no, at least at the beginning of the XML-schemas, we had to
    choose either simpleContents (only text) or complexType with
    child elements. Could be not true anymore today (there is
    a possibility of mixed='true' in complexContents elements) 
    but it was claimed to be bad practice. Again code generators
    would fail (I don't know if this is still true), at it makes
    at least very difficult to define which tags are acceptable
    within the text, therefore validation and parsing problems. 
    I don't think this 'mixed' atrtibute has ever been used in 
    any of the IVOA XML-schemas (I checked the schemas available
    from the IVOA pages). Could somebody point me to such an
    IVOA schema ?

>> And it was felt better to do this change now
>> than forbidding such extensions.
>
>felt by who?  felt why?  why not make that change in one go when
>the additional structure is actually added rather than do half the
>job now and (maybe) half at some unspecified point in the future?

===> Please Mark don't be so nasty ! Obviously we do not know now
     what will be the future needs, but I feel it is important
     not to forbid future evolutions. This change in <INFO>
     was decided at the Beijing meeting and presented in the
     plenary session of conclusions on the Friday.

>> As for example of "unit" usage:
>>   <INFO name="delay" value="3.5" unit"d">
>>     <DESCRIPTION>
>>       The result should come out within 3days and 12 hours
>>     </DESCRIPTION>
>>   <INFO>
>> A <PARAM> could be a better way, but <PARAM> cannot appear
>> in the same location of a VOTable: <INFO> is meant to give
>> informational details about for instance errors or warning
>> of the process(es) generating the VOTable, where <PARAM>
>> is not acceptable.
>>
>> Another example I have in mind could be
>>    <INFO name="field-of-view" value="10x20" unit"arcmin">
>>     <DESCRIPTION>
>>       The actual window was reduced to 10x20arcmin due to the
>>       unexpected degraded quality of data near the edges.
>>     </DESCRIPTION>
>>   <INFO>
>>
>> May these short example illustrate the practical possible
>> interest of this modification ?
>
>Thank you for these concrete examples, I now see what you have in mind.
>
>However these look like a muddled compromise to me.  I think in these
>cases it would be equally clear to write:
>
>  <INFO name="delay" value="3.5 days">...
>  <INFO name="field-of-view" value="10x20 arcmin">...
>
>and in the large majority of cases (for instance
><INFO name="QUERY_STATUS" value="ERROR"/>) the unit attribute
>makes no sense.  Any software which is processing such an INFO element
>will have to make decisions about whether and how to present the units
>alongside the value.  API which can access an INFO must provide
>additional methods to manipulate the units.  This additional load
>is not all that great in each particular case, but I see very little
>or no benefit provided.
>
>Separating the value from the units is only really useful/sensible
>if you want to do something with the value which can't be done
>if they are not separated.  That is the case for numeric values
>but not as far as I can see for string ones.

==> not only -- a separate unit can be better validated, and
    you should normally expect better reliability in the
    unit contents.

>If you think it is important to be able to put numeric values,
>which can be interpreted as numeric, where an INFO goes, then why
>not give it the option of having proper numeric values like PARAM?
>I just don't see the logic or consistency behind how this has been
>designed.
>
>> For the implementors who want to be compatible with the
>> 2 versions (1.1 and 1.2) it means in practice accept
>> a text embedded within <INFO> and </INFO> as if it were
>> surrounded by the <DESCRIPTION> and </DESCRIPTION> tags.
>> Do you feel this is a big source of trouble, or improving
>> the VOTable documentation could be a viable solution ?
>
>Like I've said, I'll do it if there's a good reason to
>(I've already likely spent longer arguing about it than it would
>take to make the implementation changes).
>
>But if the change is poorly justified or even makes things worse then
>I don't think it should be adopted into the standard.
>VOTable is a widely used standard within the VO.  It's already
>become clear that the change to INFO causes complications for TAP
>(http://www.ivoa.net/forum/dal/0902/1012.htm), and there will
>probably be others.  If we want to make changes there should be
>a robust justification for them.  I haven't yet seen one for this
>case.
>

===> Finally you are right -- discussions take much more time
     than adapting the code of our applications :-). But it's
     really a surprise for me that such a debate occurs now --
     I tried to constantly draw attention to this change
     (at least in TAP and DAL groups)

--Francois
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
=======================================================================