Expressing 2- and 3-D coordinates

[Arnold Rots]

Let me try to draw some conclusions from the discussion, so far.
But one comment to preface that: I'd be very hesitant to encourage
multiple STC-based schemata; that also was the main rationale for
rejecting STCLite.


VO schemata ultimately will need to support list types since arrays
are such an integral part of our data.  In that context and
considering that such a list type is the more natural way to express
coordinate vectors (though I realize that this is my subjective
judgment) the present use of lists of doubles for coordinate vectors
would be preferable.

Ed promises us that list will be supported in XPath2, that it will
become reality by the end of February, that parsers will incorporate
the support soon after that, and that support is currently available
through extensions.
In summary: it can be handled now with a little bit of extra effort
and in three months it will not be an issue anymore.

So, we are left with two questions:

1. Can the VOEvent community live with the extra effort for three
   months?

2. Is Ed's prognosis accurate?

(Though not necessarily in that order)

If the answer to the first question (potentially amended by the answer
to the second one) is affirmative, we'll stick with what we have,
aside from the already planned modifications that had been agreed to
before.
If the answer is no, we have three options:

a. STC sticks with list types and VOEvent may do something else.

b. STC temporarily converts to enumerating the vector components as in
   my first message, and changes back to list types when list support
   is firmly there.

c. STC converts permanently to separate the components witin the
   vector element.

Comments?

  - Arnold


Ed Shaya wrote:
> Rob Seaman wrote:
> 
> > I was hoping to ignore this conversation, oh well.
> >
> > I question the assertion that there has been "trouble" with the STC  
> > specification - just the normal back and forth with any standard  
> > format or interface as it faces different stakeholders.  Arnold was  
> > responsive to our needs (basically for general targeting coordinates,  
> > not just RA and Dec) by producing the STCLite schema.  I gather you  
> > guys vetoed STCLite.  Really don't want to have the discussion to  
> > figure out if that is your mandate.  In any event, we (the VOEvent  
> > WG) have revisited the issue and have made one little suggestion - a  
> > suggestion that it appears other folks have previously made.  Would  
> > expect the discussion to continue until a consensus is formed.
> >
> > It is a VO-wide issue, not specific to VOEvent, to assert a  
> > preference for schemata that are widely supported by parsers in the  
> > field.
> >
> Part of the problem with xs:list and some other schema items is that 
> processing requires XPath2.  Xpath1was developed before Schema and so 
> does not know anything about any schema item that is not also DTD.  
> Xpath2 is now a Candidate Recommendation scheduled to be a 
> Recommendation around Feb 28.  So we happen to be at a time where to 
> benefit from schema work you need to use extensions to standard 
> processors.  But in 3 months time the extensions will become the 
> standards.  Meanwhile, validation of things like xs:list are working 
> fine for schema aware parsers.  Atomization takes place in 
> downprocessing like XSLT which usually are not schema aware in the first 
> place (excepting Saxon.SA).
> 
> > Question whether "archival ingest, registry, retrieval, and query"  
> > cover all the bases of the VO.  Strongly agree with Alasdair that  
> > VOEvent will be an important facility of the VO as well as of the  
> > broader astronomical community - it's more than just "having  
> > Institution A alert Institution B that it saw something".  Question  
> > the wisdom of freezing the scope of the VO before the VO acquires a  
> > user base.  Didn't think "virtual" was intended to apply to its user  
> > community.
> 
> The VO user base includes everyone.  But the VO project space can not 
> include all projects.
> 
> >
> >> The VO should provide a fairly exacting set of scientific  
> >> standards.  Projects  are free to  create copies  of the schema  and  
> >> knock out  parts and change required  elements to  optional   ones.
> >
> >
> > Suspect I'm not the only one to question the wisdom of this point of  
> > view.  Is this free-for-all really preferable to having just two  
> > standard choices of STC and a simplified STCLite?  For an important  
> > facility such as STC, it is quite reasonable to expect multiple  
> > stakeholders such as VOEvent to influence the development of a common  
> > standard.  Suggest this would be simplified in the future were a  
> > User's Guide to STC available.
> >
> It would be great if two STC schema is all everyone ever needs.  But if 
> you accept STCLite then you accept the wisdom of the view.  STCLite is 
> STC with elements knocked out to satisfy a specific project.   And that 
> is fine.  Some projects are going to knock out a few more things some, a 
> few less, some will add somethings of their own.
> 
> > Rob
> > seaman at noao.edu
> 
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------