vo-dml in votable

[Laurino, Omar]

Hi Markus,

At this point I believe both solutions have strengths and drawbacks. One
solution (only one TYPE) puts less burden on the server side, but more on
the client. The other (more than one TYPE allowed) puts less burden on the
client and more on the server side.

Regarding your questions:
  - Where to draw the line? in the old mapping document (the one using
UTYPEs) the line was drawn at model boundaries. You did not need to add the
multiple types annotations for subtypes of types defined inside the same
model. The reason is that if you assume knowledge of a model, then you
don't need more help. However, after my prototyping efforts I suggested we
also included explicit declaration of abstract types even within model
boundaries, just to simplify discovery of relevant instances (assuming
types are declared abstract for a good reason).

  - How to "compute" the leaf type? I believe in the old mapping document
we suggested a specific order for the type declaration. Now that we have a
specific element maybe we might add an attribute, e.g. <TYPE leaf="true">?

In any case, as I said, I don't think you can make a strong case in either
direction. Both solutions have Pros and Cons. However, this does argue for
4b over 4a, as 4b can be turned in 4c easily if required.

Omar.

On Mon, Mar 9, 2015 at 6:50 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

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


-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20150309/e21b0964/attachment.html>