Expressing 2- and 3-D coordinates

Wed Dec 14 06:36:56 PST 2005

Quoting Arnold Rots <arots at head.cfa.harvard.edu>:

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

Yes, that's what I said.  My points are:

Context gives assocation, not type.  Snippets *should* be self-typed and
self-described (at all levels) without relying on assumed context to do so.  

Type description *should* be in the schema, where it can be used to define and
validate, not spread between the instance document and a (dis)associated
human-only document that a programmer/astronomer has to find.

Finally, XML can and should be readable and, where possible, 'obvious', at all
levels.  

Cheers

Martin

> 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:
> > 
> > <DEFANGED_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/
> --------------------------------------------------------------------------
> 
> 

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