[vodml] EnumLiterals and vodml-id

[CresitelloDittmar, Mark]

On Fri, Jan 15, 2016 at 9:19 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:

> Hi Mark
>
> >...
> >
> >       These models we are working (DatasetMetadata, STC2, etc) are
> working
> > to be vo-dml compliant to facilitate this path, but must also serve the
> present
> > and near-term, where we have model aware, but not vodml aware software.
> >
> I would be very interested to see examples of this Model aware software,
> for I think this has been sorely missing so far. Examples of software that
> "code against a model". I'm meeting with Tom today to talk about precisely
> that.
>
>
I would consider existing WCS software 'model aware' of the STC2 transform
components.



> >
> >       So, if I define vo-dml compliant enumeration in the
> DatasetMetadata model
> >          SpectralBand
> >             + Radio
> >             + XRay
> >
> >       what value would a data provider need to give in order for model
> > aware, but not vo-dml aware software to be able to instantiate the proper
> > literal instance on
> >
> >         myObject.band:SpectralBand[1]
>
> This depends on the implementation of the model in the software, something
> VO-DML is silent about.
>

For the EnumLiteral, I'm not sure it can be.  The job of an Enumeration is
to define a specific set of
values which are allowed, other values should be illegal.  For EnumLiteral,
the value and the type are
intimately connected.

A data provider can tag their products with the proper vodml-id for the
matching EnumLiteral, but
their local value is not legal unless it matches the EnumLiteral name.
vo-dml aware software would
have the option of ignoring the local value and instantiating based on the
vodml-id alone.



> It also depends on what you mean by being "model aware".
> Even if the software aims to represent the model 1-1 there are still going
> to be implementation and language dependent choices that must be made.
>
> Now I have XSLT that transforms a VO-DML model to POJO Java classes,
> though I have not kept it up-to-date with latest changes. There an
> Enumeration is mapped to a Java 'enum' and the EnumLiterals directly to the
> literals in the enum. I.e. similar to the example I sent yesterday in reply
> to Laurent's comments
> and the values to be used to set appropriately typed attributes would be
> these literals.
> But everyone is free to use their own implementation in principle.
>

Provider A implements the model and codes the SpectralBand.XRay literal to
use the string "X-ray" because that is what their products use.
Provider B implements the model and codes the SpectralBand.XRay literal to
use the string "XRay" because they are new and doing a 1-1 match with the
model.

Serializations from A will have string values "X-ray" with vodml-ids
"ds:SpectralBand.XRay"
Serializations from B will have string values "XRay" with vodml-ids
"ds:SpectralBand.XRay"

When these are passed to a validator to test model compliance, won't A
products generate an error because the value does not match any literal?



> I think the issue is mainly important if the software is to be
> interoperable with other resources. If messages need to be sent between
> them.
> Now it depends on the serialization that is chosen to represent instances
> of the data model. Annotated VOTable is one way to do so, and the only one
> we're currently explicitly working on. Software that makes particular
> choices for representing the model will have to be able to interact with
> such representations and in general will have to map from the annotated
> VOTable to its internal representation. This in fact is what Tom and I are
> trying to work on.
>
>
Well, interoperability certainly is a consideration, especially with
existing software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160115/7e693782/attachment.html>