Expressing 2- and 3-D coordinates

[Roy Williams]

> Of course, the same nesting would apply to all other appearances of
> multi-dimensional coordinates, e.g., in regions.  And the referencing
> mechanism would have to be propagated through all nesting levels.

Perhaps both representations can be allowed? Extending to the following 
scheme would completely backward compatible for existing STC 
applications:

<Value2>140 69</Value2>
or
  <Value2split>   <C1>140</C1>    <C2>69</C2>    </Value2split>

> - Would it be so difficult to modify the VOTable schema to allow arrays
> within a tabular cell?

I think the discussion is about the STC schema, not about VOTable. In 
VOTable, the <TD> element contains a string that represents a list of 
primitives, and must be parsed by the application. Splitting the string 
has no clear benefit. I think that making this change to VOTable would 
simply break a lot of applications that already use it.

However, in STC, the <Value2> element contains a list of floats, and 
splitting it means each element contains a single float, so it can be 
validated, parsed, and code-generated by a wider class of code.

> - How difficult would it be for the average XML parser to understand 
> it?

My understanding is that some XML parsers and code generators do not 
work well with the list element <Value2>140 69</Value2>, and that is 
why this alternate is proposed.





California Institute of Technology
626 395 3670
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1558 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20051213/93063b2b/attachment-0001.bin>