Expressing 2- and 3-D coordinates

[Arnold Rots]

The problem with snippets is that they don't show the whole context.
The information on the types of coordinates is provided in the
associated coordinate system description.

  - Arnold

martin hill wrote:
> 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
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------