Expressing 2- and 3-D coordinates
seaman at noao.edu
Thu Dec 15 15:22:42 PST 2005
> The VO user base includes everyone. But the VO project space can
> not include all projects.
We are discussing a function - for the sake of argument, a function
of one variable:
usage = f(individual)
You are commenting on the domain of the function - although one might
assert this is more like "everyone with a networked computer". We
are really interested in the range of the function, i.e., in
maximizing actual VO users.
The VO project space may not include all projects, but it likely
should include those with funding, such as VOEvent.
> 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.
Uh - no.
> STCLite is STC with elements knocked out to satisfy a specific
No - STCLite is implemented via an entirely separate schema.
> 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.
But that is not what you said. You said:
> Projects are free to create copies of the schema and knock out
> parts and change required elements to optional ones.
An STC "typed" element with added "somethings" might be supported by
an STC schema that would allow for adding certain somethings.
An STC typed element with a few things "knocked out" will certainly
be supported by a schema (like STC) in which those subelements/
attributes are optional.
Your suggestion amounts to the statement that anybody can claim VO
conformance while using any schemata they feel like using - to
"create copies" and to "change required elements to optional elements".
VOEvent uses a wide range of standard VO technology. The WG reached
a consensus to use STC. The majority of the WG would have preferred
an STC with "common sense" defaults, but that was the only basic
issue with using STC. STC has been a bit of a moving target in the
mean time - and not, I think, primarily because of pressure from
VOEvent. XIncludes seemed like a problem - we're assured that XLink
fixes all that. We also have this conceptual issue with the wisdom
of coordinate "vectors". It sounds like other folks do, too.
Perhaps we can return to talking about the issue, and stop talking
about talking about the issue.
> I'd be very hesitant to encourage multiple STC-based schemata; that
> also was the main rationale for rejecting STCLite.
Multiple schemata does sound a bit like "SIMPLE = F" FITS files. Why
have a standard at all?
> 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.
Subjective indeed. Does anything actually *break* if a single RA/Dec
or Long/Lat pair are expressed as individual elements? Does anything
actually work appreciably *better* if these two values (in the
simple, frequent case) are expressed as a list type?
Surely, when list types are universally supported (should this ever
occur) we still won't choose to represent every element as a list?
> a. STC sticks with list types and VOEvent may do something else.
Don't want to do this. Don't think anybody else really wants VOEvent
to, either. Ultimately though, the existence of a consensus is more
important than what the consensus turns out to be (within reason).
> 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.
These are equivalent for all practical purposes. Doubt that v1.21 is
intended to be the final version of STC. Our grandchildren can
always reconsider in a future version.
> 2. Is Ed's prognosis accurate?
Not likely. Phil Massey once suggested selling IRAF insurance. Will
Ed cover the point spread?
More information about the votable