Hi! On Mon, Mar 9, 2009 at 10:48 PM, Jonas Ådahl <[email protected]> wrote: > > The first, SXE does not specify a way to create or edit XML elements > with a namespace prefix, such as <foo:bar ... />. >
Yep. That needs work. I think the original hacky idea was to specify the prefix with 'ns' (should be renamed!) and define what the prefixes mean as you would define regular attributes in parent elements, but this got confused in the examples. See http://mail.jabber.org/pipermail/standards/2008-September/019794.html > Secondly, an issue that has to do with Commutative and Non-commutative > edits. Commutative edits are <new .../> and <remove .../> and > Non-commutative (undoable, edits with a version) <set .../>. However > there are cases when a collaboration will fail. Running the following > edits the result that should happen is unclear. > > <new type='element' name='root' rid='GUID0'/> > <new type='element' name='foo' rid='GUID1' parent='GUID0'/> > <new type='element' name='bar' rid='GUID2' parent='GUID0'/> > <new type='element' name='confused' rid='GUID3' parent='GUID1'/> > > This will trivially create the DOM: > <root> > <foo> > <confused/> > </foo> > <bar/> > </root> > > Lets now move <confused/> to the <bar/>. > > <set target='GUID3' parent='GUID2' version='1'/> > > This edit is undoable, meaning if another set with target GUID3 and > version 1 is to be processed, the state of the <confused/> document > should revert back to version 0 which is as the original DOM is. > However, consider the undoable edit <remove/> and a following <set/> > with target GUID3 and version 1 that does a trivial change, like > changing the name of the element. > > <remove target='GUID1'/> <-- remove the now empty <foo/> from existence. > <set target='GUID3' name='confusing' version='1'/> > > As GUID3's state already has version 1 the procedure is to revert back > to the previous version, thus the parent should revert back to <foo/>, > which is not possible anymore since it has been removed. > > Any comments on this anyone? > In this unlikely event the client should folow rule 0 in section 9.3, which says that 'the "orphan" record MUST be deleted.' I think this actually means that the client should send a <remove/> to others as it does this. I should warn you though that this spec doesn't even have the status of an "Experimental XEP", as it was never accepted by the council. Development on it has also been non-existent recently as far as I know. I'd be glad to help you understand it better though if you want to continue work on it. > Jonas > Joonas ;)
