Reference implementations

Tom McGlynn (NASA/GSFC Code 660.1) tom.mcglynn at nasa.gov
Tue May 10 16:37:00 CEST 2016


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
>



More information about the dm mailing list