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