Expressing 2- and 3-D coordinates
Tamas Budavari
budavari at pha.jhu.edu
Thu Dec 15 14:58:03 PST 2005
Here is an independent measurement point: the latest .NET Framework SDK
tools that were recently released for the manufacturer (maybe 5 weeks
ago?) generate classes with strings in them, too. The tools gave no
warning when creating the C# classes either. For more details and a few
examples please have a look at my message below that I sent Arnold the
other day.
Cheers, T.
Date: Tue, 13 Dec 2005 19:49:40 -0500 (EST)
From: Tamas Budavari <budavari at pha.jhu.edu>
To: Arnold Rots <arots at head.cfa.harvard.edu>
Cc: Alex Szalay <szalay at jhu.edu>
Subject: Re: FW: Expressing 2- and 3-D coordinates (fwd)
Parts/Attachments:
1 Shown 205 lines Text
2 OK ~182 KB Text, ""
----------------------------------------
Hi Arnold,
I have figured out the dependencies and managed to generate CSharp
classes. That's great! We'll try to run this through Java, as well.
One thing I noticed is that many classes have fields that are declared to
be 'string' or generic 'object' types. Is that okay? Or perhaps some of
these are supposed to be those lists you mentioned in your email? Below
are a few examples and attached is the entire .cs file with all classes.
Do they reflect your design and intention?
public partial class constraintType {
private string vectorField;
private double offsetField;
...
}
public partial class convexHullType : shapeType {
private string[] pointField;
...
}
public partial class vector3CoordinateType : coordinateType {
private object itemField;
private object[] itemsField;
private ItemsChoiceType1[] itemsElementNameField;
private object[] items1Field;
private Items1ChoiceType1[] items1ElementNameField;
private object[] items2Field;
private Items2ChoiceType1[] items2ElementNameField;
private object[] items3Field;
private Items3ChoiceType1[] items3ElementNameField;
...
}
I'll try to learn more about the schema and figure out how to use them in
our programs but I think it would be invaluable if you could indeed visit
us for a day or so. We could write some wrappers that in turn could be
used to define the interface of e.g. the footprint services.
Cheers, T.
On Thu, 15 Dec 2005, Arnold Rots wrote:
> 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/
> --------------------------------------------------------------------------
>
More information about the dm
mailing list