<div dir="ltr"><br><div>I'm wondering if this case plays a role in this discussion.</div><div><br></div><div>When creating code from a vo-dml/xml representation, there can be conflicts between the element 'name' and the target language type.</div><div><br></div><div>For example, if I remember right, something like  "ds:Target.class" would not be implementable in Java since 'class' cannot be a variable name.<br></div><div>The code would be forced to modify the attribute name into something acceptable for the language.  </div><div><br></div><div>Model-savvy serializations (eg: MIVOT)</div><div>  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.</div><div>  o with vodml-id: the modified attribute name becomes irrelevant because the vodml-id remains constant and is used in the output serialization.</div><div><br></div><div>Since the implementation would need both concepts to handle conflicts anyway, having the static/constant vodml-id incorporated into the workflow makes things simpler.</div><div><br></div><div>Mark</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 1, 2023 at 3:07 AM Paul Harrison <<a href="mailto:paul.harrison@manchester.ac.uk">paul.harrison@manchester.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 28 Feb 2023, at 14:02, Laurent Michel <<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>> wrote:</div><br><div><div>Hello DM,<br><br>The purpose of this mail is multiple<br>- Stop blurring the "MIVOT: fully qualified attribute names" thread with considerations on VODML<br>- Specifying the roles of both VODML-IDs and names<br>- Assess their impact on the recommended models<br></div></div></blockquote><div><br></div>It is relatively easy to assess impact on the existing models - validate  against the latest version of the VO-DML tools - see <a href="https://github.com/pahjbo/PhotDM/tree/vodml-tools-integration" target="_blank">https://github.com/pahjbo/PhotDM/tree/vodml-tools-integration</a> as an example - note that the the integration happens within the existing</div><div>model github repository and does not take much effort <a href="https://github.com/ivoa-std/PhotDM/commit/0477e6739123b645ae921c62ed3f07143b0d2961" target="_blank">https://github.com/ivoa-std/PhotDM/commit/0477e6739123b645ae921c62ed3f07143b0d2961</a></div><div><br><blockquote type="cite"><div><div><br>Each VODML element has a name and a VOMDL-ID.<br>From the standard point of view:<br>- Both must comply with a regexp.<br>- names must be unique within their enclosing type or package (section 4.1.2)<br>  in simpler word: we cannot have 2 attributes with the same name.<br>- VODML-IDs must be unique within the document (section 4.1.1)<br>- nothing is said about the way to build these 2 fields<br>- nothing is said about the way they are connected to each other.<br></div></div></blockquote><div><br></div>At the very minimum I think that the VO-DML standard needs some updating because of these last two points<br><blockquote type="cite"><div><div><br>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.<br>For this reason :<br>- All referable elements must have a VOMDL-ID unique within the document.<br>- Non referable elements (e.g. attributes) could live without  VODML-ID<br><br>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).<br></div></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div>Note that there are other things in the VO-DML schema that I think are repeating information - <a href="https://github.com/ivoa/vo-dml/issues/6" target="_blank">https://github.com/ivoa/vo-dml/issues/6</a><br><blockquote type="cite"><div><div><br>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.<br></div></div></blockquote><div>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.</div><br><blockquote type="cite"><div><div>Anyway I won't be the one who will have to manage this.<br><br><br>Laurent<span id="m_2304531583599138974cid:7E793879-44F1-4C36-ABDB-CB169DAD9D9A"><Capture d’écran de 2023-02-28 14-36-50.png></span><span id="m_2304531583599138974cid:91D5176B-74BC-4B78-B811-F83BFFD935D2"><laurent_michel.vcf></span></div></div></blockquote></div><br></div></blockquote></div>