Reference implementations

[Matthew Graham]

But a data model is not a protocol.

-- Matthew

On May 10, 2016, at 4:37 PM, Tom McGlynn (NASA/GSFC Code 660.1) wrote:

> This kind of using the fact that you have written a definition of the model counting as an implementation of the model sounds awfully incestuous. I have always read the requirement as having two different groups using the protocol in some service, ideally one that supports doing astronomy.
> 
>    Tom McGlynn
> 
> Matthew Graham wrote:
>> So once we have a mapping standard with reference implementations any DM model specified in VO-DML could automatically have a reference implementation (according to these criteria) which would make life easier. Time to get that mapping spec out :)
>> 
>> -- Matthew
>> 
>> 
>> 
>> On May 10, 2016, at 4:00 PM, Laurino, Omar wrote:
>> 
>>> 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 <mailto: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 <mailto: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
>> 
>