MIVOT: fully qualified attribute names

[Paul Harrison]

> On 8 Mar 2023, at 16:54, Laurino, Omar <olaurino at cfa.harvard.edu> wrote:
> 
> My point is that the answer to some of your comments may depend on the kind of client we are implementing and how we want to use the data. For example, a client might be interested in all the instances that contain std:Type.attribute1 and std:Type.attribute2, irrespective of the instance type they belong to, duck-typing style, confident that the semantics of those attributes are exactly what they are supposed to be according to the std: data model. How does a mapping specification enable that while also allowing a client who couldn't care less about specific types to provide a dictionary-like, weakly typed, human readable representation of the same instance? Note that in neither case there's any just-in-time parsing of the model xml documents. In the former case the data model is assumed and maybe even hard coded in the client's implementation, in the other it is completely ignored. Other use cases might include a pre-parsing of the model xml, or even a just-in-time parsing.
> 
> If one wants to leave the door open for additional usages of the serialization, using the full vodm-id provides a future proof solution for a little price in terms of complexity.

I understand these use cases and this is where I possibly hijacked this thread a little - most of my comments are really discussing usages of VODML-ID in the VODML document itself, not whether to use fully qualified attribute names in MIVOT. I also tried to make the point that in MIVOT it is really usage of VODML-REFs that are under discussion, and that if Appendix C becomes a “MUST” then a VODML-REF can be mechanically generated from the VO-DML structure - it is not actually dependent on there being VODML-ID elements in a VO-DML instance document. I am trying to get away from the idea that VODML-IDs are “just an identifier” that is implied in the main body of the VO-DML standard document, as I think that this is less useful than acknowledging that they have the structure advised by Appendix C.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230309/caaeefe0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20230309/caaeefe0/attachment.p7s>