OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: UID discussion


Hi Karim (and other folks),

I was having a hard time identifying some of the uneasiness I felt towards UIDs - hopefully this email makes more sense than my ramblings on the call.

First, let me summarize what the existing documentation is.  The original XMILE draft from Karim notes "every display object includes a unique identifying number" (section 5.3.1.1).  Billy's section 5 draft is more restrictive "This attribute is a unique linearly increasing integer which gives each display object a way to be referred to specifically" (section 5.4.1).

Additionally, on the phone I believe we were discussing UIDs not only as a sequence of increasing positive integers, but as the sequence of integers from 1 to N, where N is the number of display entities nested under a <view> tag (currently stocks/flows/auxes don't have UIDs - I am assuming we would add UIDs to them).  I am mentioning this because it is a prerequisite for being able to safely use an array or std::vector to hold display entities.

I dislike this additional specificity for several reasons.  First, it is somewhat inconsistent.  It implies that display tags are written out in the order of their UID, which I do not believe is explicitly specified anywhere.  If this is true, it means position in the list of display entities must equal UID number - but the order of entities is already used for resolving z-index ordering.  I don't think that coupling z-index ordering to UID in XMILE file is a positive thing.  Additionally, to me, having a requirement that fields in a list must be in increasing order is non-intuitive and prone to error - it means I can't just copy/paste something in or reverse the order of 2 elements without changing their UIDs.  Taken a step further, if the UID sequence has a max of N, the number of display tags in a <view>, I can't delete a <connector> without modifying the UID of every entity with a higher UID, making hand-editing and simple scripts close to useless in certain situations.

So, to recap, having the max UID be $NUM_DISPLAY_TAGS means that any deletion of a <display> requires the modification of every subsequent UID.  But it doesn't stop there - you now have to update every reference to every changed UID.  Suddenly deleting a connector requires having to fully parse a <view> section.

Requiring the UID to match the order the tag appears is (to me) counter-intuitive in an otherwise intuitive spec, and results in similar cascading issues when cut/copy/pasting or reordering tags - it requires a full parse of a <view> section, rather than just rearranging a DOM.  This seems like a major downside for the ability to use a std::vector instead of a map when reading in display tags.

Finally, it precludes implementations from having stable UIDs across saves/loads, which I see as being potentially useful in vendor-specific ways.  It would be nice to know that given 2 copies of a model, say revision 1 and revision 13, a connection between aux A and aux B is the same one, as opposed to having been deleted in revision 4 and added back in 12 - it can be thought of as potential metadata about the modeling process.

In conclusion, I propose that we not prescribe that <display> tags be written out with increasing UIDs, and additionally that we not specify the max UID for a given <view> tag be the number of <displays> contained within.  I think Karim's original wording is good, and additionally we could add that the UID fall within the range of [1-UINT64_MAX).

If you've read this far, kudos and thank you :)

yours,
Bobby


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]