[vodml] EnumLiterals and vodml-id

[Laurent Michel]

Hello,

The current discussion about EnumLiterals is somehow similar with this about multiplicity.
The question is not to find a pattern on which VO-DML fails. It is quite robust and I'm pretty sure that a work around can 
always be found (DataTypes encapsulated in ObjectTypes, using a semantic instead to label the EnumLiterals...) .

What I am asking myself is to know why (a few) patterns ([0...n]) or labels (X-ray) widely used in our domain have been 
discarded from VO-DML.
I did find a clear response in these long threads which are more focused on the "how to" than on the "why".


Cheers
Laurent


Le 15/01/2016 18:11, CresitelloDittmar, Mark a écrit :
>
>
> On Fri, Jan 15, 2016 at 9:19 AM, Gerard Lemson <glemson1 at jhu.edu <mailto: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.
>
>
>
>

-- 
jesuischarlie

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34