Expressing 2- and 3-D coordinates

[Arnold Rots]

A question has come up on expressing multi-dimensional STC coordinates
in the context of VOEvent that I would like to put to the DM forum.

In the STC schemata I have implemented coordinate vectors and error
matrices for 2-D and 3-D spatial coordinates as lists of 2, 3, 4, or 9
doubles - the equivalent of arrays of specific length.
It is perfectly clear and unambiguous XML and it leads to something
like:

<Position2D>
  <Value2>140 69</Value2>
  <Error2Matrix>0.05 0.0 0.0 0.05</Error2Matrix>
</Position2D>

As you may be aware, there have been complaints about this, not only
from people in VOEvent but also in VOTable, who want to separate the
coordinates.  We have always argued that these coordinates need to be
considered as a vector and should not be treated as separate items -
for one thing, errors, sizes, and regions are functions of the vectors
in non-separable form.

Now an old proposal has been presented again (I believe it was
considered and rejected before) and we need to think about it.
It is to make the individual vector components separate elements
within a vector element, resulting in:

<Position2D>
  <Value2>
    <Coord1>140</Coord1>
    <Coord2>69</Coord2>
  </Value2>
  <Error2Matrix>
    <M11>0.05</M11>
    <M12>0.0</M12>
    <M21>0.0</M21>
    <M22>0.05</M22>
  </Error2Matrix>
</Position2D>

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.

The impetus for this is a desire to appease VOEvent articipants who
have complained that parsers have trouble parsing the lists of doubles.
I believe this is a valid issue since XPath1 does not handle
individual elements in lists; XPath2 is supposed to but there are
rumors that it might not.  On the other hand, one might argue, of
course, that one should always retrieve the entire vector.

The problem, of course, is that it seems a rather laborious way to
describe something that is available and supported by XML Schema (list
types) and it makes the documents even more verbose.
On the other hand, it would also resolve one of the issues that
VOTable has with STC.  Although in that case use of groups (to mimic
the lists) are also an appropriate solution.

VOEvent has been told that this had to be run by DM - like STCLite -
and might be rejected on solid grounds.  Here I don't quite see the
problems that STCLite had but I'd welcome any thoughts and wisdoms you
may have on this issue.

Cheers,

  - Arnold


--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------