Re: [xmile] UID discussion

[Bob Eberlein <bob@astutesd.com>]

Hi Bobby,

You reminded me that I forgot to put the minutes up.

I think what we centered in on the discussion is that the UIDs be 
nonnegative integers without gaps when the entire contents of the view 
have been read. The intent is to enable the use of vector and similar 
constructs when reading.

I do agree with you that requiring them to be monotonically increasing 
would be a mistake. From the perspective of writing the content out this 
does not much matter, but if someone were to go in and move some stuff 
around all of a sudden things would simply break. Similar reasoning 
suggest that the requirement of no gaps should not be depended on when 
reading (in case someone goes in and deletes a few things).

None of this speaks to implementation. There is not really any reason to 
retain the UID after reading in the XML since everything would be 
replaced by object references. We did speak briefly about persistence of 
UIDs potentially as a way to provide differences or even perhaps 
maintain a cross session undo/redo capability. I believe I brought this 
up and I didn't manage to convince myself. While it is an interesting 
notion,  it is speculative and could be implemented with a vendor 
specific GUID. The UIDs only real purpose is reading and writing.

                       Bob Eberlein

On 10/14/2013 10:42 PM, Bobby Powers wrote:
> 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