STC in VOTable: Time utypes

[Gerard]

Dear all

I will not resist the temptation to start a diatribe on substitutionGroup-s
and their use in STC-X ;-)
Now that some brave people are trying to use STC-X, their insidious nature
comes to the fore again.

Imho, substitutionGroup-s and their evil twin <element ref="..."> should not
be used in XML schemas representing a data model.

They complicate and expand XML schemas in a way that is not necessary (there
are more natural ways to use inheritance hierarchies and support
polymorphism in XML Schema) and can only with great difficulty be mapped to
more traditional data modeling contexts (OO-language, UML).

They tempt users to exceedingly ugly "anti-patterns" such as there is the
Region2 "hierarchy" in STC. This is a copy of the Region hierarchy and
introduced only because you can then define a diffType as follows

  <xs:complexType name="diffType">
    <xs:complexContent>
      <xs:extension base="regionType">
        <xs:sequence>
          <xs:element ref="Region"/>
          <xs:element ref="Region2"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

instead of the more natural
  <xs:complexType name="diffType">
    <xs:complexContent>
      <xs:extension base="regionType">
        <xs:sequence>
          <xs:element name="Region" type="regionType"/>
          <xs:element name="Region2" type="regionType"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

They complicate usage of a schema by other schemas in that they implicitly
define 100s of valid STC documents such as for example

<?xml version="1.0" encoding="UTF-8"?>
<HEE/>

Any schema wishing to import the types of STC-X cannot do so without
receiving all these root elements.
These implicitly define valid XML documents of that schema, which is likely
not what is desired. Extra validation code will therefore have to be written
simply to explicitly invalidate all those elements.

One could go on, but Registry and VOTable have both accepted that
substitutionGroup and its evil twin are undesirable and done away with them.
"ordinary" type based inheritance works there and STC's XML schema could and
should have been designed in a similar manner.

And now Arnold wants us to include this awful modeling concept in the
definition of utypes and utype syntax?

Don't !!! 

(Please please please)

It seems that both this and other applications of STC would greatly benefit
from a sanitized version of STC-X (may be derived from a proper UML version
:) ?). I would be happy to participate in an effort to create one if some
community interest exists -- maybe starting in Victoria?
I don't think the "STC-in-VOTable" effort would need to wait for the
conclusion of such an effort. It needs to be based on the STC data model and
possibly a set of UTYPEs, not on the STC-X schema implementation.


Cheers

Gerard Lemson



> -----Original Message-----
> From: Arnold Rots [mailto:arots at head.cfa.harvard.edu]
> Sent: Monday, April 12, 2010 2:54 PM
> To: Markus Demleitner
> Cc: dm at ivoa.net; dal at ivoa.net
> Subject: Re: STC in VOTable: Time utypes
> 
> I will resist the temptation to start a diatribe on utypes ;-)
> The problem is that utypes provide the leaves of the structure in
> isolation and this is particularly uncomfortable when it comes to
> substitution groups.
> I can't remember whether this was brought up before, but one solution
> might be to handle substitution groups explicitly in this way:
> use the head element in the utype and add the choice from the
> substitution group separately. Adding it as an attribute would be the
> intuitive solution, but that would get complicated when there are
> multiple layers of substitution groups. A better solution might be to
> put it in parentheses:
> 
>       stc:AstroCoords.Time.TimeInstant.AbsoluteTime(ISOTime)
> 
> That also gets us out of the issues with spatial frames:
> 
>      stc:AstroCoordSystem.SpaceFrame.SpaceRefFrame(ICRS)
> 
> Cheers,
> 
>   - Arnold
> 
> Markus Demleitner wrote:
> > Dear VOTable and DM folks,
> >
> > On the issue of a common container I've received only positive
> > feedback, so I'll go ahead and have the next draft include that.
> >
> > Meanwhile, another issue has come up that I'd like to hear opinions
> > on: The time utypes.  Currently, they look like this:
> >
> > stc:AstroCoords.Time.TimeInstant.ISOTime or
> > stc:AstroCoords.Time.TimeInstant.JDTime.
> >
> > I've just put the following diatribe on this on the wiki page
> > (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/STCInVOTable):
> >
> > """
> > That is bad for at least three reasons:
> >
> >    1. clients have a hard time figuring out what column a time or a
> time
> >       error or whatever is (since they need to check at least three
> utypes)
> >    2. we have xtype in VOTable for this purpose, and having both
> utype
> >       and xtype specify something then requires some rules on what to
> >       do when the attribute contradict or if there is some inference
> >       between them
> >    3. data models should IMHO not be concernded with serializations
> >
> > So -- what's to be done?
> >
> >    1. Keep everything as is (ugly, but probably workable; declare
> >       clashes between utype and xtype as undefined)
> >    2. Elide ISO/JD/MJDTime by special rule (but that's yet another
> >       special rule, and you cannot build an STC-X tree from utypes
> any more)
> >    3. Change STC-X (would probably take a while and might be used
> >       to clean up some other ugly spots we have here, but it's a
> >       major undertaking that would seriously delay STC-in-VOTable)
> >    4. ???
> > """
> >
> > (at the very bottom).  Emboldend by the feedback to my last question,
> > I thought I'd ask around again for opinions and suggestions --
> > preferably on the wiki.
> >
> > Thanks,
> >
> >           Markus
> >
> -----------------------------------------------------------------------
> ---
> 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/
> -----------------------------------------------------------------------
> ---