MIVOT: fully qualified attribute names

Laurent Michel laurent.michel at astro.unistra.fr
Tue Feb 28 09:40:55 CET 2023



Le 27/02/2023 à 20:31, Patrick Dowler a écrit :
> We seem to have veered a little, but that's my own fault for kind of hijacking this thread with a technical
> issue :-)

I propose to open a specific thread for this topic which is not connected with MIVOT.

> 
> I'm pretty sure the test case I provided shows that the currently published VO-DML xsd + schematron
> does not enforce the intended/correct uniqueness of attribute names within a class. In my opinion, that's
> a bug and I would guess it is something missing from the schematron doc. The alternative explanation is
> that attribute name is simply a label, but that's not really true because the xsd enforces naming
> rules on the value.
The spec enforces the name uniquness (see my message 23/02) but does set any connexion between names and VOMDL-ID

> 
> It doesn't matter how one creates the model. I prefer hand-written rather than generated from XMI
> because it is better for version control.

The lack of free version control for Modelio, and more genraly of collaborative tool is a big drawback for Modelio.
I'm still using it just for the capability of drawing diagrams and I regret that I never took the time to jump in the the Paul's 
tooling may for MANGO.

LM
> 
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 
> 
> On Fri, 24 Feb 2023 at 03:38, Paul Harrison <paul.harrison at manchester.ac.uk <mailto:paul.harrison at manchester.ac.uk>> wrote:
> 
> 
> 
>>     On 23 Feb 2023, at 18:23, Laurent Michel <laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>> wrote:
>>
>>
>>>>     Translate with https: //www.deepl.com/translator <http://www.deepl.com/translator>
>>     -- 
>>     jesuischarlie/Tunis/Paris/Bruxelles/Berlin
>>
>>     Laurent Michel
>>     SSC XMM-Newton
>>     Tél : +33 (0)3 68 85 24 37
>>     Fax : +33 (0)3 )3 68 85 24 32
>>     Université de Strasbourg <http://www.unistra.fr <http://www.unistra.fr/>>
>>     Observatoire Astronomique
>>     11 Rue de l'Université
>>     F - 67200 Strasbourg
>>
>>>     On 23 Feb 2023, at 18:59, Paul Harrison <paul.harrison at manchester.ac.uk <mailto:paul.harrison at manchester.ac.uk>> wrote:
>>>
>>>
>>>
>>>>     On 23 Feb 2023, at 14:24, Laurent Michel <laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>> wrote:
>>>>
>>>>>>     I understand, but there is no reason but he common sense, to give a particular structure to the VOMDL-IDs.
>>>>>>     We you generate VODML from XMI (modelio), you first get random IDs for the VOMDL-ID and in a second steps, there are
>>>>>>     built from [model-name, attr-name , ID of the host class], but the XSLT doing this is not part of the standard. If you
>>>>>>     edit your VOMDL by hand, like Pat did, you may introduce a distortion to this rule without breaking the schema compliance.
>>>>>>
>>>>>>     This is why I suggest to tell the users:
>>>>>>     - do not rely on names
>>>>>>     - do no parse VODML-IDs
>>>>>
>>>>>     I agree that technically the VODML-IDs are just XMLIDs andlong as they are unique within a single VODML instance that
>>>>>     they can have any value/structure. However, this is precisely the problem, as simply regarded like this, then two
>>>>>     instances of a VO-DML document describing a particular model could both be valid, but with entirely different sets of
>>>>>     VODML-IDs, and in this situation another standard like MIVOT cannot use those VODML-IDs without also saying precisely
>>>>>     which instance document is being used to describe the model. Unless there is some guarantee about the form of the
>>>>>     VODML-ID  then there could also be undesirable behaviour that new versions of a model did not retain the exact same
>>>>>     VODML-ID for a particular attribute.
>>>>>
>>>>
>>>>     I do not agree with this. Once the VODML-IDs have been set, no matter how you do it, they are part of the standard - of
>>>>     the VOMDL description of the model -. None is allowed to change them later on.
>>>>
>>>
>>>     The VO-DML standard makes no guarantee of this - it is perfectly legal for me to create the next version of the PhotDM
>>>     for instance with totally different VODML-IDs. We all agree that it is sensible that a particular model element keeps a
>>>     constant ID and better that it is human readable, and that the human can look at the structure of the VODML-ID and make
>>>     inferences about the function of that element in the model. However, the only reason that this has happened in model
>>>     instances so far is because of the XSLT processing, which you say is not part of the standard. I would like the structure
>>>     that the XSLT scripts impose to be part of the standard, so that the manual edit that Pat did would actually be
>>>     non-compliant.
>>
>>     Once your model has been reviewed and accepted, the VODML file is published on the doc repo and becomes the reference
>>     along with the spec document.
>>     None can modify it anymore out of the std&doc process.
>>     The VOMDL-IDs in that file are then frozen and can be used with absolute confidence.
>>      Changing them is equivalent to changing the standard.
>>     The stability of the VOMDL-IDs is not provided by the VODML standard but by the Std&Doc rules.
>>
> 
>     This is what the VO-DML standard says about VODML-IDs
> 
>     ----
> 
>     Identifier for the containing model element. Syntax in VO-DML/XML defined by the VODMLID type, as shown in the VO-DML/Schema
>     snippet below. This element MUST be formatted according to the regular expression in the XML schema:
> 
>     [a-zA-Z][a-zA-Z0-9_\.]*
> 
>     The value assigned to an element MUST be unique in the document and is case sensitive.
> 
>     -----
> 
>     I can follow all of  Std&Doc rules and all of the VO-DML std rules and produce PhotDM 1.2 with entirely different VODML-IDs
>     - It is not sensible, but it is legal, as the standard only says that they must be unique within the document, and does not
>     relate them to the <name> elements, so the IDs could be just random generated strings - much as happens with the XMI
>     produced by UML modelling tools. I want to update the standard to say that it there is the structure in the VODML-IDs that
>     many other things implicitly rely on when referring to model elements from outside the file.
> 
>     I am not sure why the VO-DML standard does not address this  - possibly because as generated by the tooling the VODML-IDs
>     look a lot like another definition of UType (https://www.ivoa.net/documents/Notes/UTypesUsage/
>     <https://www.ivoa.net/documents/Notes/UTypesUsage/>) and it was “easier” to avoid that issue, and just treat it as a “new”
>     way to reference data model elements. I think that was a mistake as the rigorous way that they are produced would have been
>     the opportunity to say this is the “best” UTYPE.
> 
>     Of course because the VODML-IDs are mechanically constructed it is possible to remove them….
> 
> 
>     Paul.
> 
> 
> 
> 
> 

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/vcard
Size: 406 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230228/2480bde8/attachment.vcf>


More information about the dm mailing list