Comments on V1.1

[Francois Ochsenbein]

Hi Tony et al.,

Sorry for the delay, but the way the documents have to be managed
is less than obvious... I've uploaded new versions of the document
(V1.093, PDF) and of the XSD in the VOTable twiki location 
(http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOTable). 

Several changes occured following your comments.

Some more detailed answers:

>
>   * re 1.1, para 2: VOTable as storage
>     VOTable should not be represented as a storage format. Its only purpose
>     is as a data transfer format.
>   * re 1.1, Data Storage, para 2: metadata storage
>     VOTable should not be represented as a way of storing metadata. The
>     IVOA Data Model effort will define the metadata that represents VO
>     information and the format in which it will be represented. It should
>     be made clear that the VOTable metadata representation method cannot be
>     seen as a long term solution.

  Although you are right in principle, we cannot forbid the usage of
  VOTable to store the data! The same phrases were applied to FITS
  in its early days... And in the cases where VOTable is used with
  binary data, I can't see why we should discourage its usage...

>   * re 1.1, Data Storage, para 2: 'implicit query to a server'
>     this comment should be removed; VOTable is not a query mechanism.

  Changed in V1.093

>   * re 2: Data Model
>     this section should begin with a note that the VOTable representation
>     of a Data Model will be superseded by the work of the IVOA Data Model
>     group.

  I basically disagree -- I do not see VOTable as a temporary patch
  until the (necessarily complex) final data model comes up.

>   * re 2, list of expressions: Table
>     the Table entity is not used anywhere else in the list which would fit
>     it into the VOTable definition: where does it belong?

  Yes you are right in principle -- there are two possible views of
  a VOTable as a set of metadata + associated data, or as a set of
  tables. The description emphasizes on the metadata/data view,
  but can't ignore the "set of tables" view. I've modified a bit
  this description.

>   * re 2, para 3: __Epoch__
>     refers to an 'above example' with an Epoch parameter: the example does
>     not exist

  My error, thank you for pointing it out.

>   * re 3: XML Schema
>     the link to the schema should be an ivoa.net url

  Will be in the final 1.1 document.

>   * re 3.1, last para: wrong PARAM
>     the description refers to a 'PARAM parameter (the Epoch)': the actual
>     param is Telescope

  My error, thank you for pointing it out.

>   * re 3.3, COOSYS: values
>     how are the values of COOSYS set? Is it a fixed enumerated list? If so,
>     where are the values to be found? Or can anything be put here?
  
  Not sure which "values" you are talking about -- all required
  values to define a COOSYS are specified by dedicated attributes.

>   * re 3.4, COOSYS: why?
>     what is the difference between using COOSYS here or in the DEFINITIONS
>     element?

  Several COOSYS are possible in a VOTable -- some are specific to 
  a RESOURCE and then stored there. The generic ones (typically J2000)
  would be put in the <DEFINITIONS>
  But the necessity of having a <DEFINITIONS> element is not at all
  obvious. The <DEFINITIONS> element could be removed, in my opinion,
  leaving just the necessary parameter definitions according to their 
  scope (at VOTable or RESOURCE level)

>   * re 3.4: related tables
>     in the comment, 'a RESOURCE is basically a set of related tables':
>     related in what way? Ie, how should tables be related such they can be
>     represented as a resource?

  The server basically decides... I imagine a server returns a single
  RESOURCE; several resources can then be merged into a VOTable

>   * re 3.4: recursiveness
>     if RESOURCE can be 'recursive', what does this mean? Ie what type of
>     data is being represented by a recursive resource? Would an example
>     here help?

  This schema enables the possibility of having one or several tables
  associated to a resource -- for instance a list of targets in a
  table, and several RESOURCEs giving their answer about this list.

>   * 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.

>   * re 3.5, gref: why?
>     what is the difference between href="glu://..." and gref="glu://..."?
>     'higher-level protocol' doesn't seem to be explained.

  A possible change. I don't yet see the implication on the GLU protocol
  and processing, but this has to be obviously discussed.

>   * re 3.5: content-role
>     what is the parser supposed to do with this? what does it mean?

  Again the parser does the parsing only... the application decides
  on the basis of these attributes

>   * re 3.6, para 2: father_
>     this may be a translation problem: in English, one refers to the parent
>     element, not _father

  Thanks, fixed.

>   * re 3.6, last para: ref attribute
>     would it not be better to have a separate element, REFTABLE, with no
>     FIELD & PARAM children so that user cannot put these in by mistake

  There are now FIELDref PARAMref -- we could introduce GROUPref and TABLEref

>   * re 3.6, last para: ref attribute
>     in fact, why not make such abstract definitions part of the DEFINITIONS
>     element, so that all referenced elements are in there

  The problem is that all structures have to be known before sending
  any result -- introducing unnecessary delays (quite similar to the
  FITS requirement of knowing the data size a priori)

>   * re 4.1: datatype attribute
>     this implies that the datatype attribute is not required when the ref
>     attribute is present but the schema does not allow this

  Agree, that's why FIELDref was introduced in V1.092

>   * re 4.1: ref attribute
>     presumably this is a reference to another FIELD/PARAM element? (this is
>     not stated) If so, where can the referenced FIELD/PARAM element exist -
>     anywhere, at any level? Can a FIELD ref to a PARAM and vice versa?

  Should not -- but this can't be specified in XSD, can it ?

>   * re 4.1: type attribute
>     the text says this is not part of the standard yet it appears in the
>     schema. This should be removed from both to avoid confusion or
>     included.

  my error -- fixed.

>   * 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.

>   * 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 ?

>   * re 4.7: order of GROUPed FIELDs
>     if FIELDs are contained in a GROUP, how does this resolve in the order
>     of TD elements in the TABLEDATA element? Or must the TDs be grouped in
>     the same way?

  I've tried to make this more explicit -- the TD's are in the same order
  as their declaration.

>   * re 4.7, second example: ref
>     do referenced FIELDs have associated TD columns in the TABLEDATA? What
>     are these example FIELDs referencing, given that the ref values are the
>     same as the FIELD elements they are replacing. I think this example is
>     somewhat confusing.
>   * re 4.7, third example: order of FIELD/PARAMs
>     is there any meaning to the order of FIELD and PARAM elements apart
>     from the order of the TD elements? eg, when parsed are the PARAM values
>     returned as if they were embedded in the TDs in the order that the
>     PARAM elements are embedded within the FIELDs?
>   * re 5, first para: ref FIELDs
>     what does a reference to a "true" column mean? Section 4 does not
>     explain this; there is nothing anywhere else in the document about true
>     columns.

  I hope this is clarified in the last (1.093) version.

>   * re 5.1, para 4 (immediately after diagram): reader
>     what is the reader and where is it defined what the reader must do?

  OK -- to be removed.

>   * re 5.1, last para: trailing blanks
>     this also refers to how the data is read (parsed?). If parsing
>     instructions are to be part of the spec they should be highlighted more
>     prominently - given a separate section perhaps.

  Yes one of the assumptions is that the same data can be written in any 
  of the possible serialization modes without any change in the metadata
  description -- this could effectively be highlighted.

>   * re Appendix A: extensions
>     I don't think possible extensions are a valid part of the
>     specification; they should be contained in a separate IVOA Note
>     document and only referenced in this document as a warning to users of
>     the spec that some part may be changed in the future.

  I'm not in favor of several documents -- references to the discussions
  and the history is useful.


Again, thank you Tony for your comments.

Cheers, Francois

================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 17
================================================================================
WARNING -- Messages in HTML only are assumed to be spam and are destroyed.
NOTE -- Les messages ne contenant que du HTML sont assimiles a du pourriel.
================================================================================