MIVOT: fully qualified attribute names

Harrison Paul harripa at gmail.com
Tue Feb 28 17:51:11 CET 2023



> On 28 Feb 2023, at 14:06, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Hi Paul,
> 
> On Tue, Feb 28, 2023 at 01:40:13PM +0000, Paul Harrison wrote:
>>> On 28 Feb 2023, at 09:48, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>>> 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.
> 
> Out of curiosity: Why do you think that?  How do you see that as
> superior to XSD-style
> 
>  <instance dmtype="prefix:classname">
>    <attribute role="simple_name"...>
> 
> ?  I mean, I could be wrong, but I still feel we're putting a lot of
> effort into something (vodml-ids) we simply don't need at all.

I think I agree with you in the sense that I do not see any reason for putting full paths for the 
value of the role attribute as the context is clear from the enclosing instance definition, but the dmtype attribute should be a VODML-REF - classname might consist of enclosing packages for instance.

So you are right similar arguments can be used to simplify MIVOT too. I guess I made the statement that I did because
I was thinking that if necessary MIVOT could easily construct VODML-REFs  even if VODML-IDs were removed from VO-DML. A while ago in this thread I did say that you could have the short attribute names if you wanted…but the implied reason was wrong - I then said from the structure of the VODML-ID string, but it is really from the structure of the model elements.

Paul.


More information about the dm mailing list