vo-dml in votable

[Mark Taylor]

Gerard et al.

following other peoples comments and explanations, I'll give
my thoughts on the VO-DML in VOTable business, though I don't
claim any great expertise on it.

Regarding the options 4a, 4b and 4c, the question seems to be
fairly clearly about whether a VODML element should have only
a single role and type (in which case 4a: <VODML type="t" role="r"/>
makes sense) or whether there are cases where multiple roles/types
are required (in which case 4c with ROLE, TYPE children or
4b with ROLE, TYPE, ALTTYPE children of VODML).

I don't feel I understand the role/type business, or the expected
applications of VO-DML, deeply enough to have a firm opinion on
this question.  I'll note that Markus mentioned polymorphism
and Gerard mentioned [java] member classnames; both of those
examples/illustrations make me think about the requirement one
often has in OO programming to know multiple different
types/behaviours associated with an object (in java, the hierarchy
of superclasses and whatever different interfaces implemented)
not just a single "type".  That leads me to think that multiple
declared TYPEs might be necessary for some purposes.
(That wouldn't necessarily mean there's the expectation for
data providers to always document all types in this way).
However, perhaps I'm pushing the analogy too far.  Either
way ALTTYPE seems unattractive.  So I would cautiously back 4c,
but if it's clear to those who understand this stuff better than
I do that one ROLE and TYPE per VODML element is always sufficient
then in the interests of enforcing that restriction, and of tidiness,
4a would be better.

Another option would be to use 4a but define the type attribute
in such a way that it's possible to put multiple type values in it.
The existing *4a.xsd declares the VODML/@type attribute with
content type xs:string; by convention you could use a space as
a separator as long as type values never have spaces (might they?).
If you know you want multiple type values it would be better to
have multiple TYPE child elements or if the syntax fits to define
@type with content type=NMTOKENS.  But as long as it's syntactically
possible to put multiple types in an attribute it would leave
an escape clause if it turned out later we'd said 4a when we
really need multiple TYPEs.

Regarding the disruption of incorporating a new element into
the VOTable document: it's a pain to have to come up with a new
version of the VOTable standard, but I doubt that any of these
options will cause serious compatibility problems in practice
to VOTable parsers - at least it won't for STIL (hence topcat
and stilts etc).  If anybody is using parsers rigidly tied to
the XSD then obviously there might be noticable upgrade issues;
I don't know if that applies to any of the VOTable parsers in use.
>From this point of view I can't imagine any of the options 4a/4b/4c
would be significantly better or worse than the others.

As long as we do it right (rather than e.g. starting off with 4a
in VOTable 1.4 and then needing VOTable 1.5 later to accommodate 4c)
I think it will be less disruptive to keep this all in the VOTable
document than to introduce a VODML placeholder in VOTable and point
to another document.

It's still not clear to me how far this is going to affect my
day job, but as far as it generates markup of the kind that
I would want to consume in stil/stilts/topcat I will try to
cooperate (e.g. with changes to my client code) with prototypers
or data providers producing VOTables implementing this stuff
in the interests of testing etc.

Mark


On Wed, 11 Feb 2015, Gerard Lemson wrote:

> Dear all
> It would be nice if we could quickly agree how to annotate VOTable elements
> with metadata pointing to VO-DMl data models.
> In the votable/vo-dml session in Banff we came to a decision to add a new
> element to VOTable that would represent this mapping and would take the
> place of the utype attributes we had assumed to use for that in the current
> mapping document in
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx
> .
> The detailed design of this element was still left open and I sent out an
> email shortly after the interop in which I made some suggestions, which I
> thought I had adequately illustrated with examples of the possible XML
> schema snippets. Maybe this was not clear, so I have updated the contents of
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable
> It now contains for three possible designs, labeled 4a, 4b and 4c, full
> VOTable schemas and three corresponding versions of a VOTable following
> these schemas and showing the different ways to annotate the same tables.
> 
> E.g.
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd
> is a possible new schema and
> https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml
> an annotated VOTable following that design.
> 
> Note that in the three different proposals only the *content* of the
> <VODML> elements, as described by the structure of the VODMLAnnotaiton
> complexType definition, is different. Their association to PARAM, GROUP,
> PARAMref and FIELDref elements is the same.
> 
> Please let me know if this is still not clear or comment on the design
> possibilities.
> 
> Cheers
> Gerard
> 
> 
> 
> On Wed, Oct 15, 2014 at 5:47 PM, Gerard Lemson <gerard.lemson at gmail.com>
> wrote:
> 
> > Dear all
> >
> > During the VO-DML-in-VOTable discussion at the last interop we decided to
> > go
> > with (something like) proposal 4 on the wiki at
> >
> > https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab
> > le/VOTable_Prop4.xml  Other options can be found in the same folder.
> > What we now need is to finalize the design for the XML tag(s) to add to
> > VOTable.
> > I have created a mockup of an XML schema with a complexType definition
> > reflecting the new element.
> > The design used in proposal 4 above is represented by proposal 4a in the
> > schema. It has attributes for role and actual type, and elements for
> > alternative types. Proposals 4b and 4c vary on this theme. All use a
> > simpleType definition reflecting the model-prefix+':'+vodml-id pattern used
> > to refer to VO-DML elements. See the mapping document for more detailed
> > descriptions (taking into account the fact that that document will have to
> > be updated with the choice to be made here).
> >
> > Note, I am not making statements on whether these two types must be in the
> > VOTable targetnamespace. Andreas had some thoughts on this that I hope he
> > will send to the list in reply.
> >
> > And obviously the final design may differ from these proposals if
> > necessary,
> > but let's please converge on an acceptable design soon so Omar and I can
> > update the mapping document.
> >
> > Cheers
> > Gerard
> >
> >
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/