vo-dml in votable

[Markus Demleitner]

Hi Omar, dear lists,

On Fri, Mar 06, 2015 at 11:11:48AM -0500, Laurino, Omar wrote:
> I would like to elaborate on the ALTTYPE element and why it was included in
> the design.

Thanks for the elaboration.  Since I'm a big python fan, it is
perhaps not terribly surprinsing that I still prefer duck
typing (and hence a unique type annotation, with naive clients
working on the attribute names/utypes/vodml-ids).

However, assuming we want explicit annotation of the inheritance
hierarchy, the argument

> 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.

convinces me to prefer

> I would then prefer something like option 4b but with an open multiplicity
> for the TYPE element, so one would have:
> 
> <GROUP>
>   <VODML>
>      <TYPE>sdss:SDSSSource</TYPE>
>      <TYPE>src:Source</TYPE>
>   </VODML>
> ....
> </GROUP>

over ALTTYPE.  *If*, and here I don't see terribly clearly, we're
sure we never need the concept of "actual type" in the VODML context.
The trouble here is that with such a convention, the implementation
of a function

  type(object) -> class-of-object

would probably require inspecting all VO-DML files mentioned in the
file in order to figure out which is at the leaf of the inheritance
tree, right?

If we forsee the necessity for the type function, I hence believe we
should have ALTTYPE (if we want multiple types annotated at all).

> There is another interesting use case where alternate types can greatly
> simplify the life of the client implementor: abstract types. Let's say that

True -- but the attribute names work as abstract types, too (in your
example, you'd be following the pointer to the error role, right?)

So, the problem, as far as I can see, only exists for root-level,
global objects that are not referenced by any other VO-DML object.
Maybe that's an indication that it's not a problem of type annotation
but of data model declarations?  I'm not actually suggesting this at
this point, but something that'd be attractive for many other reasons
(and again wouldn't need VOTable changes) might be an inventory of
root objects for a given data model within each data model
declaration -- for instance, it'd also help applications find these.


>    <VODML>
>      <ROLE>stc:SkyPosition.error</ROLE>
>      <TYPE>mydm:MyEllipseError"</TYPE>
>      <TYPE>stc:EllipseError</TYPE>
>      <TYPE>stc:SkyError</TYPE>
>    </VODML>

Hmwell, yes, you see, this is what makes me skeptical.  We'll have to
formulate requirements or validity criteria, on what types VOTable
writers will have to put here.  What would that be?

"Writers MUST include one TYPE element for each class in the
inheritance chain"?  That would incur a large baggage as you have
fairly long inheritance chains even within a given model, and I'm
quite sure you wouldn't want to dump these every time you write an
annotation.

"Writers MUST include one TYPE element for each class in the
inheritance chain until an IVOA recommended data model is reached"?
That would fix the worst uglyness, but apart from difficulties while
developing such data models, I'm a bit nervous making the
serialisation dependent on something as volatile as IVOA's set of
standards (which changes roughly five times a year).


To sum up: I believe the only thing multiple types give you that
attribute names/utypes don't is allowing easy *top level* DM element
localisation for *naive clients*.  If this turns out to be a relevant
use case, I'd say let's look at object directories in the DM
declarations (which can be useful for other things, too) before
futzing with the type calculus.

Cheers,

        Markus