<div dir="ltr"><div>Hi All,</div><div><br></div><div>I would like to elaborate on the ALTTYPE element and why it was included in the design.</div><div><br></div><div>Let's say that one has a rather simple Source class like this:</div><div><br></div><div>Source</div><div>--------</div><div>name : string</div><div>position : SkyPosition</div><div><br></div><div>Let's assume SkyPosition is defined in some way in the "stc2" model.</div><div><br></div><div>In this simple example, the Source class would be defined in a standard "src" DM and data providers would be free to extend it in their own models, for example with a subclass like this:</div><div><br></div><div>SDSSSource -----|> Source</div><div>---------------------</div><div>description : string</div><div><br></div><div>The following vodml-ids (we don't call them utypes anymore) are defined by the "src" model:</div><div><br></div><div>src:Source (the Source type)</div><div><br></div><div>src:Source.name</div><div>src:Source.position (of type stc2:SkyPosition, defined by stc2)</div><div><br></div><div>The "sdss" model adds the following vodml-ids:</div><div><br></div><div>sdss:SDSSSource (the SDSSSource type)</div><div><br></div><div>sdss:SDSSSource.description</div><div><br></div><div>An SDSSSource instance, according to option 4a, would be serialized in VOTable as follows:</div><div><br></div><div><GROUP></div><div> <VODML type="sdss:SDSSSource"/></div><div> <PARAM ... value="M51"></div><div> <VODML role="src:Source.name"/></div><div> </PARAM></div><div> <GROUP></div><div> <VODML role="src:Source.position" type="stc2:SkyPosition"/></div><div> .... Position serialization here ....</div><div> </GROUP></div><div> <PARAM ... value="my favorite galaxy"></div><div> <VODML role="sdss:SDSSSource.description"/></div><div> </PARAM></div><div></GROUP></div><div><br></div><div>Notice that since SDSSSource extends Source, it inherits all its vodml-ids, but it shadows the Source's type vodml-id. In the serialization, you don't find src:Source, although SDSSSource is indeed both an instance of sdss:SDSSSource and src:Source.</div><div><br></div><div>How can a reader find the standard src:Source type in the above snippet?</div><div><br></div><div>One approach, somewhat Pythonic I would say, might be considered a form of duck typing: as long as an instance has the attribute src:Source.position, a reader might say, I am going to treat it as a src:Source instance. Notice that this is a stronger version of duck typing (maybe type inference is a closer concept in terms of programming languages): the uniqueness of the vodml-ids implies that if an instance has an attribute with the vodml-id src:Source.position then the instance *must* be a src:Source.position instance.</div><div><br></div><div>ALTTYPE (or any similar element) makes things explicit, so that the reader does not need to infer the type by the presence of its attributes. In the above examples one would have:</div><div><br></div><div><GROUP></div><div> <VODML type="sdss:SDSSSource"></div><div> <ALTTYPE>src:Source</ALTTYPE></div><div> </VODML></div><div> ....</div><div></GROUP></div><div><br></div><div>Now, a reader can simply look for src:Source and must not rely on any kind of type inference. The problem with 4a and ALTTYPE is that readers need to explicitly look for two different XML elements to get a single piece of information.</div><div><br></div><div>I would then prefer something like option 4b but with an open multiplicity for the TYPE element, so one would have:</div><div><br></div><div><GROUP></div><div> <VODML></div><div> <TYPE>sdss:SDSSSource</TYPE></div><div> <TYPE>src:Source</TYPE></div><div> </VODML></div><div>....</div><div></GROUP></div><div><br></div><div>In the above snippet, readers only have to query the XML instance for GROUPs with the src:Source TYPE in order to get all the instances they are interested in. I would say that this is more "Java-like", as it is more explicit and possibly redundant. Again, this is just an analogy: in both cases, with or without the ability to specify multiple types, the instance could be said to be "type safe", i.e. a GROUP containing elements with src:Source.* ROLEs can only belong to a src:Source instance (given the serialization is valid, i.e. there are no mistakes).</div><div><br></div><div>To summarize, "alternate" type is probably a misleading term. What we are talking about is close to the OO concept of polymorphism, where the same object may be an instance of multiple types, even without multiple inheritance support (VODML does not support multiple inheritance as this is a rather tricky pattern to implement in the relational model, and that would complicate the data provider's life). Explicitly annotating the serialization with all the supertypes IDs may make the reader's life easier and less error prone. However, from a strictly technical point of view, readers have ways to find the information they seek even without the supertype annotation.</div><div><br></div><div>Notice that in all of the above I am referring to "naive" clients, i.e. readers that *do not* parse the VODML descriptions, but just assume the a-priori knowledge of a data model and its utypes. Pardon me, vodml-ids. Clients that do parse the VODML descriptions do not care that much, as they can find all the information they need. In my opinion the only reason to have the supertype annotation is to simplify the reader's life.</div><div><br></div><div>A corollary to what I am saying is that I prefer option 4b over 4a because it allows, at the very least, to keep the multiplicity of the TYPE element open, which is something you cannot achieve with 4a.</div><div><br></div><div>What I don't like about 4b is that it brings forth all the verbosity of XML. However, I will send a different message regarding my take on the different options on the table.</div><div><br></div><div>There is another interesting use case where alternate types can greatly simplify the life of the client implementor: abstract types. Let's say that you have an abstract SkyError type that can be extended by concrete EllipseError, CircleError, etc.... If the client wants to instantiate the right corresponding class in its code (let's say a plotting application that needs to instantiate the correct graphic class for rendering the error on the sphere), the explicit supertype annotation provides a simple handle: readers can query for the abstract type's vodml-id and identify the XML snippet that refers to the error, and then instantiate different classes according to the concrete type. Without the "alternate type" readers would need to probe all possible known concrete subtypes. Even worse, since the subtype might itself be a custom subtype of a standard model, readers have to fall back to type inference by blindly probing for the attributes of all the possible known subtypes.</div><div><br></div><div>Say that I extend EllipseError and derive MyEllipseError, the XML snippet would look like this:</div><div><br></div><div><GROUP></div><div> <VODML></div><div> <ROLE>stc:SkyPosition.error</ROLE></div><div> <TYPE>mydm:MyEllipseError"</TYPE></div><div> </VODML></div><div> <PARAM ... value="8.5"></div><div> <VODML></div><div> <ROLE>stc:EllipseError.positionAngle</ROLE></div><div> </VODM></div><div> </PARAM></div><div>....</div><div></GROUP></div><div><br></div><div>How does a client aware of the standard stc but not of my extension know that it has to instantiate an EllipseError rather than a CircleError? It would need to scan for attributes like stc:CircleError.radius and stc:EllipseError.positionAngle. With the alternate types, though, one would have:</div><div><br></div><div><div><GROUP></div><div> <VODML></div><div> <ROLE>stc:SkyPosition.error</ROLE></div></div><div> <TYPE>mydm:MyEllipseError"</TYPE></div><div> <TYPE>stc:EllipseError</TYPE></div><div> <TYPE>stc:SkyError</TYPE></div><div><div> </VODML></div><div> <PARAM ... value="8.5"></div><div> <VODML></div><div> <ROLE>stc:EllipseError.positionAngle</ROLE></div><div> </VODM></div><div> </PARAM></div><div>....</div><div></GROUP></div></div><div><br></div><div>With only one added line, things are trivial for the reader now: just query the XML for GROUPs with a stc:SkyError TYPE, and then instantiate the correct object (e.g. an ellipse shape) according to the concrete type (e.g. EllipseError).</div><div><br></div><div>Again, I am not arguing that without the supertype annotation things are impossible for a client, just that with the supertype annotation things are easier and do not require type inference.</div><div><br></div><div>Hope this helps,</div><div><br></div><div>Omar.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 5:26 PM, Mark Taylor <span dir="ltr"><<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Gerard et al.<br>
<br>
following other peoples comments and explanations, I'll give<br>
my thoughts on the VO-DML in VOTable business, though I don't<br>
claim any great expertise on it.<br>
<br>
Regarding the options 4a, 4b and 4c, the question seems to be<br>
fairly clearly about whether a VODML element should have only<br>
a single role and type (in which case 4a: <VODML type="t" role="r"/><br>
makes sense) or whether there are cases where multiple roles/types<br>
are required (in which case 4c with ROLE, TYPE children or<br>
4b with ROLE, TYPE, ALTTYPE children of VODML).<br>
<br>
I don't feel I understand the role/type business, or the expected<br>
applications of VO-DML, deeply enough to have a firm opinion on<br>
this question. I'll note that Markus mentioned polymorphism<br>
and Gerard mentioned [java] member classnames; both of those<br>
examples/illustrations make me think about the requirement one<br>
often has in OO programming to know multiple different<br>
types/behaviours associated with an object (in java, the hierarchy<br>
of superclasses and whatever different interfaces implemented)<br>
not just a single "type". That leads me to think that multiple<br>
declared TYPEs might be necessary for some purposes.<br>
(That wouldn't necessarily mean there's the expectation for<br>
data providers to always document all types in this way).<br>
However, perhaps I'm pushing the analogy too far. Either<br>
way ALTTYPE seems unattractive. So I would cautiously back 4c,<br>
but if it's clear to those who understand this stuff better than<br>
I do that one ROLE and TYPE per VODML element is always sufficient<br>
then in the interests of enforcing that restriction, and of tidiness,<br>
4a would be better.<br>
<br>
Another option would be to use 4a but define the type attribute<br>
in such a way that it's possible to put multiple type values in it.<br>
The existing *4a.xsd declares the VODML/@type attribute with<br>
content type xs:string; by convention you could use a space as<br>
a separator as long as type values never have spaces (might they?).<br>
If you know you want multiple type values it would be better to<br>
have multiple TYPE child elements or if the syntax fits to define<br>
@type with content type=NMTOKENS. But as long as it's syntactically<br>
possible to put multiple types in an attribute it would leave<br>
an escape clause if it turned out later we'd said 4a when we<br>
really need multiple TYPEs.<br>
<br>
Regarding the disruption of incorporating a new element into<br>
the VOTable document: it's a pain to have to come up with a new<br>
version of the VOTable standard, but I doubt that any of these<br>
options will cause serious compatibility problems in practice<br>
to VOTable parsers - at least it won't for STIL (hence topcat<br>
and stilts etc). If anybody is using parsers rigidly tied to<br>
the XSD then obviously there might be noticable upgrade issues;<br>
I don't know if that applies to any of the VOTable parsers in use.<br>
>From this point of view I can't imagine any of the options 4a/4b/4c<br>
would be significantly better or worse than the others.<br>
<br>
As long as we do it right (rather than e.g. starting off with 4a<br>
in VOTable 1.4 and then needing VOTable 1.5 later to accommodate 4c)<br>
I think it will be less disruptive to keep this all in the VOTable<br>
document than to introduce a VODML placeholder in VOTable and point<br>
to another document.<br>
<br>
It's still not clear to me how far this is going to affect my<br>
day job, but as far as it generates markup of the kind that<br>
I would want to consume in stil/stilts/topcat I will try to<br>
cooperate (e.g. with changes to my client code) with prototypers<br>
or data providers producing VOTables implementing this stuff<br>
in the interests of testing etc.<br>
<br>
Mark<br>
<div><div class="h5"><br>
<br>
On Wed, 11 Feb 2015, Gerard Lemson wrote:<br>
<br>
> Dear all<br>
> It would be nice if we could quickly agree how to annotate VOTable elements<br>
> with metadata pointing to VO-DMl data models.<br>
> In the votable/vo-dml session in Banff we came to a decision to add a new<br>
> element to VOTable that would represent this mapping and would take the<br>
> place of the utype attributes we had assumed to use for that in the current<br>
> mapping document in<br>
> <a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/MappingDMtoVOTable-v1.0.docx</a><br>
> .<br>
> The detailed design of this element was still left open and I sent out an<br>
> email shortly after the interop in which I made some suggestions, which I<br>
> thought I had adequately illustrated with examples of the possible XML<br>
> schema snippets. Maybe this was not clear, so I have updated the contents of<br>
> <a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable</a><br>
> It now contains for three possible designs, labeled 4a, 4b and 4c, full<br>
> VOTable schemas and three corresponding versions of a VOTable following<br>
> these schemas and showing the different ways to annotate the same tables.<br>
><br>
> E.g.<br>
> <a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable-1.3_vodml4a.xsd</a><br>
> is a possible new schema and<br>
> <a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votable/VOTable_Prop4a.xml</a><br>
> an annotated VOTable following that design.<br>
><br>
> Note that in the three different proposals only the *content* of the<br>
> <VODML> elements, as described by the structure of the VODMLAnnotaiton<br>
> complexType definition, is different. Their association to PARAM, GROUP,<br>
> PARAMref and FIELDref elements is the same.<br>
><br>
> Please let me know if this is still not clear or comment on the design<br>
> possibilities.<br>
><br>
> Cheers<br>
> Gerard<br>
><br>
><br>
><br>
> On Wed, Oct 15, 2014 at 5:47 PM, Gerard Lemson <<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a>><br>
> wrote:<br>
><br>
> > Dear all<br>
> ><br>
> > During the VO-DML-in-VOTable discussion at the last interop we decided to<br>
> > go<br>
> > with (something like) proposal 4 on the wiki at<br>
> ><br>
> > <a href="https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab" target="_blank">https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/samples/votab</a><br>
> > le/VOTable_Prop4.xml Other options can be found in the same folder.<br>
> > What we now need is to finalize the design for the XML tag(s) to add to<br>
> > VOTable.<br>
> > I have created a mockup of an XML schema with a complexType definition<br>
> > reflecting the new element.<br>
> > The design used in proposal 4 above is represented by proposal 4a in the<br>
> > schema. It has attributes for role and actual type, and elements for<br>
> > alternative types. Proposals 4b and 4c vary on this theme. All use a<br>
> > simpleType definition reflecting the model-prefix+':'+vodml-id pattern used<br>
> > to refer to VO-DML elements. See the mapping document for more detailed<br>
> > descriptions (taking into account the fact that that document will have to<br>
> > be updated with the choice to be made here).<br>
> ><br>
> > Note, I am not making statements on whether these two types must be in the<br>
> > VOTable targetnamespace. Andreas had some thoughts on this that I hope he<br>
> > will send to the list in reply.<br>
> ><br>
> > And obviously the final design may differ from these proposals if<br>
> > necessary,<br>
> > but let's please converge on an acceptable design soon so Omar and I can<br>
> > update the mapping document.<br>
> ><br>
> > Cheers<br>
> > Gerard<br>
> ><br>
> ><br>
><br>
<br>
</div></div>--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div>