MIVOT: fully qualified attribute names

[Paul Harrison]

> On 28 Feb 2023, at 09:48, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Dear DM,
> 
> On Tue, Feb 28, 2023 at 07:34:07AM +0000, Paul Harrison wrote:
>> No irritating VODML-IDs to invent there….
> 
> Ha!  And that's where it is a MIVOT issue after all -- this entire
> thread wouldn't have happened if we decided to sunset the VODML-ids
> now.  It's still easy at this point, and it'll be nigh impossible
> once MIVOT uses them.

I think that there is a actually a distinction to be made between VODML-IDs and VODML-REFs (which in most of the usage I have seen are effectively UTypes) - MIVOT itself should only be using VODML-REFs to refer to model elements.
> 
> As I said, I'll not block anything as long as I'm the only one who's
> publicly coming out against VODML-ids -- but I'd very much welcome
> ignoring them wherever we use VODML.  They only cause headache (like
> here) without doing anything the conventional (class name).(attribute
> name) couldn't do.  Really: they are not more than an accident
> resulting from the history of VO-DML.  An accident, by the way, that
> we can still fix at this exact point before its damage radius
> includes anything our users and adopters can see.

I have tried to argue in this thread, that the way that VODML-IDs are defined in the standard at the moment is positively harmful in that it allows random strings not related to the model type names - In practice changing the definition of VODML-IDs to be UTypes (i.e. made up of the name elements of the ancestry of a particular model element) would not be incompatible with the practice of virtually all the VO-DML expressed models in existence as they have been processed by the standard tools before publishing to have a form that is equivalent to UType. Once it is agreed that the VODML-IDs are UTypes then they can be dropped entirely as they are mechanically created from the model structure.

Paul.
-------------- 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/20230228/e86c1ef9/attachment.p7s>