MIVOT: fully qualified attribute names

[Patrick Dowler]

We seem to have veered a little, but that's my own fault for kind of
hijacking this thread with a technical
issue :-)

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.

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.

--
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>
wrote:

>
>
> On 23 Feb 2023, at 18:23, Laurent Michel <laurent.michel at astro.unistra.fr>
> wrote:
>
>
> —
> Translate with 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
>
> On 23 Feb 2023, at 18:59, Paul Harrison <paul.harrison at manchester.ac.uk>
> wrote:
>
>
>
> On 23 Feb 2023, at 14:24, Laurent Michel <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/)
> 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.
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230227/2412db86/attachment.htm>