<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 9:19 AM, Gerard Lemson <span dir="ltr"><<a href="mailto:glemson1@jhu.edu" target="_blank">glemson1@jhu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mark<br>
<br>
>...<br>
<span class="">><br>
> These models we are working (DatasetMetadata, STC2, etc) are working<br>
> to be vo-dml compliant to facilitate this path, but must also serve the present<br>
> and near-term, where we have model aware, but not vodml aware software.<br>
><br>
</span>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.<br>
<span class=""><br>
</span></blockquote><div><br></div><div>I would consider existing WCS software 'model aware' of the STC2 transform components.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> So, if I define vo-dml compliant enumeration in the DatasetMetadata model<br>
> SpectralBand<br>
> + Radio<br>
> + XRay<br>
><br>
> what value would a data provider need to give in order for model<br>
> aware, but not vo-dml aware software to be able to instantiate the proper<br>
> literal instance on<br>
><br>
> myObject.band:SpectralBand[1]<br>
<br>
</span>This depends on the implementation of the model in the software, something VO-DML is silent about.<br></blockquote><div><br>For the EnumLiteral, I'm not sure it can be. The job of an Enumeration is to define a specific set of <br></div><div>values which are allowed, other values should be illegal. For EnumLiteral, the value and the type are <br></div><div>intimately connected.<br><br></div><div>A data provider can tag their products with the proper vodml-id for the matching EnumLiteral, but<br></div><div>their local value is not legal unless it matches the EnumLiteral name. vo-dml aware software would<br></div><div>have the option of ignoring the local value and instantiating based on the vodml-id alone.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also depends on what you mean by being "model aware".<br>
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.<br>
<br>
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<br>
and the values to be used to set appropriately typed attributes would be these literals.<br>
But everyone is free to use their own implementation in principle.<br></blockquote><div><br></div><div>Provider A implements the model and codes the SpectralBand.XRay literal to use the string "X-ray" because that is what their products use.<br></div><div>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.<br><br></div><div>Serializations from A will have string values "X-ray" with vodml-ids "ds:SpectralBand.XRay"<br></div><div>Serializations from B will have string values "XRay" with vodml-ids "ds:SpectralBand.XRay"<br></div><div><br></div><div>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?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
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.<br>
<span class=""><br></span></blockquote><div><br></div><div class="gmail_quote">Well, interoperability certainly is a consideration, especially with existing software.<div><br><br><br><br></div></div></div></div></div>