Expressing 2- and 3-D coordinates

[martin hill]

The issue is not really whether lists are better space-separated or
tag-separated.  The issue is this:

On Dec 13, 2005, at 15:58, Alberto Micol wrote:
>
>Why the coordinates cannot be treated as an array in [IVOA XML docs] ? 
>

Vectors or arrays are suitable where the values are indeed a list of values _of
the same type._ In all other cases the values should be within a tag that can
properly describe and type the value it encloses.

I know some of you think in terms of n-dimensions and 'let n go to...' for
specific cases.  This gives you the two options that Arnold presented, ie:

<Position2D><Value2>
   <Coord1>140</Coord1>
   <Coord2>69</Coord2>
</Value2></Position2D>

or

<Position2D>
  <Value2>140 69</Value2>
</Position2D>

and there is no significant difference between these two, and you might as well
use the first (if, as seems to be the case, parsers can handle lists properly).

But if you have a tag like "values" you ought to look at why the tag's _name_ is
a _type_ (after all, the type should be described in a schema) instead of
providing meaning.

Coordinates are not of the same type.  The limits to RAs & DECs for example are
quite different.  Similarly, at a level above, cartesian coordinates are
different to polar coordinates, which have different attributes, and using the
same XML snippet for both loses type information (and therefore contract
description and validation).

XML has encapsulation to provide association, and ascii tags to provide some
semantics.  So it can be used to provide useful information about the 'specific
cases'. 

So the example should be:

<PlateCenter type="Polar">   
   <RA>140</RA>
   <DEC>69</DEC>
</Position>

or:
 
<Velocity type="Cartesian">
   <X units='km'>140</X>
   <Y units='m'>69</Y>
</Position>

or:

<ObjectCenter type="Pixel">
   <X>140</X>
   <Y>69</Y>
</Position>

as appropriate.  

Errors should be associated with the values by encapsulation and
self-documenting tag(s) where possible, not by position in an associated list. 

When you look at this snippet:

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

I'm afraid this does not look clear and it's certainly ambiguous.  Are these
pixels or polars?  Which way round does the error matrix apply?  It is only
obvious to someone already familiar with the STC model, not to haplass software
engineers or researchers who 'just want to use' the document.

As Paul H has pointed out, the *primary* purpose of XML is for computers to
read.  Typing the values properly means we can specify contracts properly for
our interchange documents, and validate them as fully as possible.  But as they
are also human readable, you have an opportunity to make exchange documents that
are also relatively self-documented, and therefore much easier to understand,
use, explain and maintain.

Cheers

Martin

-- 
Martin Hill
VOTech Software Engineer @ ROE
www.roe.ac.uk/~mch
+44 7901 55 24 66


Quoting Ed Shaya <Edward.J.Shaya.1 at gsfc.nasa.gov>:

> It makes little difference for Value2. Either way is fine with me.   But 
> once people notice that if they use the correct parser arrays are 
> possible in XML, and then we can move generally to having data arrays of 
> length appropriate for astronomy.  VOTable should be composed of  
> xsd:list elements so that one is not repeating <td> tens of millions of 
> times.
> 
> I might note that ChemML has had XML arrays since 1999, even before 
> xsd:list.  The chemists realized that arrays
> are so important that standard XML parsers needed to be enhanced to 
> include them.  Now this is no longer necessary.
> http://www-ece.engr.ucf.edu/~jza/classes/4781/XML/XML.html  (search for 
> array).
> 
> 
> Ed
> 
> 
> Matthew Graham wrote:
> 
> > Hi,
> >
> > Just to add my tuppence worth here: the bottom line really has to be 
> > that the XML representation is implementable in a platform-independent 
> > way. You just have to go with the lowest common denominator: it really 
> > matters not one jot if
> >
> > <Value2> 149.60 23.5</Value2>
> >
> > is the most elegant representation but cannot be parsed properly by a 
> > sizeable fraction of our systems, you just have to use
> >
> > <Value2>
> >  <C1>149.60</C1>
> >  <C2>23.5</C2>
> > </Value2>
> >
> > instead. The moment we start mandating a particular infrastructure to 
> > support our XML, we sound the death knell from the user community.
> >
> >       Cheers,
> >
> >       Matthew
> 
> 
> 
> 


-- 
Software Engineer
Astrogrid, ROE (www.astrogrid.org)
Mob: +44 7901 55 24 66
Fax: +44 131 668 82 64