VODML, VODML-ID and names

[CresitelloDittmar, Mark]

I'm wondering if this case plays a role in this discussion.

When creating code from a vo-dml/xml representation, there can be conflicts
between the element 'name' and the target language type.

For example, if I remember right, something like  "ds:Target.class" would
not be implementable in Java since 'class' cannot be a variable name.
The code would be forced to modify the attribute name into something
acceptable for the language.

Model-savvy serializations (eg: MIVOT)
  o without vodml-id:  would need to retain the original name of the
modeled element in order to output that to the serializations.  This would
have to be finagled by the implementation.
  o with vodml-id: the modified attribute name becomes irrelevant because
the vodml-id remains constant and is used in the output serialization.

Since the implementation would need both concepts to handle conflicts
anyway, having the static/constant vodml-id incorporated into the workflow
makes things simpler.

Mark


On Wed, Mar 1, 2023 at 3:07 AM Paul Harrison <paul.harrison at manchester.ac.uk>
wrote:

>
>
> On 28 Feb 2023, at 14:02, Laurent Michel <laurent.michel at astro.unistra.fr>
> wrote:
>
> Hello DM,
>
> The purpose of this mail is multiple
> - Stop blurring the "MIVOT: fully qualified attribute names" thread with
> considerations on VODML
> - Specifying the roles of both VODML-IDs and names
> - Assess their impact on the recommended models
>
>
> It is relatively easy to assess impact on the existing models - validate
>  against the latest version of the VO-DML tools - see
> https://github.com/pahjbo/PhotDM/tree/vodml-tools-integration as an
> example - note that the the integration happens within the existing
> model github repository and does not take much effort
> https://github.com/ivoa-std/PhotDM/commit/0477e6739123b645ae921c62ed3f07143b0d2961
>
>
> Each VODML element has a name and a VOMDL-ID.
> From the standard point of view:
> - Both must comply with a regexp.
> - names must be unique within their enclosing type or package (section
> 4.1.2)
>  in simpler word: we cannot have 2 attributes with the same name.
> - VODML-IDs must be unique within the document (section 4.1.1)
> - nothing is said about the way to build these 2 fields
> - nothing is said about the way they are connected to each other.
>
>
> At the very minimum I think that the VO-DML standard needs some updating
> because of these last two points
>
>
> The reason for having different uniqueness rules is that VODML documents
> are built as flat lists  of elements that has to be put together by solving
> references (VODML-REF) against VOMDL-IDs.
> For this reason :
> - All referable elements must have a VOMDL-ID unique within the document.
> - Non referable elements (e.g. attributes) could live without  VODML-ID
>
> The problem now is that the VODML-IDs are here and everywhere and removing
> them would require an upgrade of the VODML schema and  also of all the
> models based on VODML (PhotDM, Meas, Coord, Provenance) since those models
> directly refer to VODML-IDs (see enclosed screenshot from Meas).
>
>
> My assertion is that because of the structure that was imposed “behing the
> scenes” by the VO-DML tools, that the actual changes necessary are not as
> drastic as they first seem. It would potentially affect people like Pat
> (who did not use the standard tools) in more disruptive manner.
>
> The schema could be easily updated with to make the vodml-id optional and
> the VO-DML standard document updated with more clarifying text - there
> could even be some clarification put in on how to interpret "VODML-ID" when
> it occurs in model standard documents, so that they could remain unchanged
> as my assertion is that VODML-REFs everywhere would not need to be changed.
>
> Note that there are other things in the VO-DML schema that I think are
> repeating information - https://github.com/ivoa/vo-dml/issues/6
>
>
> As this is not a blocking issue for MIVOT or the incoming high level
> models (Cube, MANGO) either, it would be wise not to press on the Replay
> button of the last 8 years history.
>
> I don’t think it is anything like hitting the replay button - it is a
> tidying up of the mechanics of processing the VO-DML files, all of the
> concepts remain in the language, and models.
>
> Anyway I won't be the one who will have to manage this.
>
>
> Laurent<Capture d’écran de 2023-02-28 14-36-50.png><laurent_michel.vcf>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230307/c57152a7/attachment-0001.htm>