[Standards-JIG] proto-JEP: SVG Whiteboarding

[Bishop, Michael W. CONTR J9C880]

>> Changing the Stacking Order of the Elements (4.5.2):  We've used a
>> more fine-grained approach.  To rearrange an element's place in the
>> tree, we use a combination of "beforeId", "afterId", and "parentId".
>> If "beforeId" is specified and "afterId" is not, the element must be
>> the first element in a group before the element with the given
>> "beforeId".
>>
>> If "afterId" is specified and "beforeId" is not, the element must be
>> the last element in a group after the given "afterId".  If both
"afterId"
>>
>> and "beforeId" are specified, the element must become the only
element
>> between the two elements with the specified IDs.  If "parentId" is
>> specified, the element becomes the first child of that parent.  These
>> rules help with potential synchronization issues.
>>

> I had a lengthy discussion about this with Boyd just now, I think your
> method's one big downside is that adding elements is not commutative
with
> adding other elements. So if two users are trying to write a sentence
at
> the same time for example, some strokes will be accepted from one and
some
> from the other...

I had another thought about that.  The "afterId" and "beforeId" are
typically used for reordering an element's Z-order position in the DOM
tree.  If we change the rule for "parentId" to read "If a parentID is
specified, the element becomes the LAST child of that parent.", this
would cover the main use case.  When you draw to a "layer" or a
specified parent element, you typically append the new element to the
end of the child list.  So in an instance like this, neither
simultaneous element would be rejected:

<g id="1"/>

User 1 sends:
<rect parentId="1" .../>

User 2 sends:
<ellipse parentId="1" .../>

Regardless of which one the server processes first, both will be
appended as the "last" child of the "g" element, one after the other
without breaking any rules.

Michael Bishop