Reference implementations

[Laurino, Omar]

Hi,

I agree with Gerard that items 1) and 2) look like the same, unless one
brings in a standard for instance serializations. Since we can have
standardized mapping strategies (as different recommendations) that map
instances of valid VODML/XML models and their standard serializations, I
don't think a valid serialization of an instance should be required for
data models: this should be guaranteed by the mapping standard(s) and their
reference implementations.

As for the ModelImport requirement, it makes sense for "low level" models
but not for "high level" ones, plus there is no way to guarantee that all
types defined by a model are extendable/usable by other models. It gets too
complicated.

I would suggest we include the "model import" evidence as a "soft
requirement", to be evaluated on a case-by-case basis depending on the use
cases of the model. For STC, it makes a lot of sense to require this
additional proof of interoperability, because the model is intended to be a
building block for other models.

Or, we might be to *require* that at least one reference implementation is
a mission/archive/service-specific model that extends the standard one. So,
if we had a model for Sources/Catalogs, at least one reference
implementation should be a mission/archive/system-specific model that
proofs the model can be meaningfully extended by actual specializations.
Other than properly validating as VODML/XML, this model should be evaluated
for its domain-specific content, and that's probably not something you can
automate. This should also be a good way to involve implementors from the
community, so it's probably my preferred one.

Omar.


On Tue, May 10, 2016 at 9:38 AM, Gerard Lemson <gerard.lemson at gmail.com>
wrote:

> Hi
> What is meant by item 2, "An XML serialization of the DM".
> The standard representation (serialization?) of a VO-DML data model is
> VO-DML/XML, i.e. XML. And that is the representation that can be validated
> (step 1?) using automated means, for example using XSLT scripts in the
> vo-dml/xslt folder on volute at gavo.
> If 2) is meant to imply an XML serialization of an *instance* of the
> model, that we can only do once we have a standard XML representation of
> instances of models. That does not yet exist. The original VO-URP framework
> does contain an automated XML Schema generator for its version of VO-DML,
> that has not yet been ported to VO-DML.
> And of course the mapping document describes how one can describe
> instances serialized in VOTable, but that is a different standard.
>
> For what it's worthy, I think that an "implementation of VO-DML" is a data
> model expressed using that language (in VO-DML/XML to be precise) and
> validated using software. The latter enforces that the language should
> allow automated validtion.
> I think interoperable implementations of VO-DML are two or more valid
> models that are linked by "modelimport" relationships. I.e.one model
> "imports" the other(s) and uses types from the other as roles or super
> types in the definition of its own types. This is supported by the
> VODMLID/VODMLREF meachanism of the language.
>
> Cheers
> Gerard
>
>
>
> On Tue, May 10, 2016 at 9:04 AM, Matthew Graham <mjg at cd3.caltech.edu>
> wrote:
>
>> Hi,
>>
>> We're trying to define specifically what would satisfy the reference
>> implementation requirement for an IVOA Spec in the context of a data model.
>> The proposal is that:
>>
>> (1) If the DM has been described using VO-DML it can be validated as
>> valid VO-DML
>>
>> (2) An XML serialization of the DM can be validated
>>
>> so therefore is the combination of the two sufficient to demonstrate the
>> validity and potential interoperability of the data model (which is the
>> purpose of the reference implementations).
>>
>>         Cheers,
>>
>>         Matthew
>
>
>


-- 
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/dm/attachments/20160510/8245b6e2/attachment-0001.html>