Subject: [Simple] Clarifications of some XCAP (+diff) issues

From: Jari Urpalainen <[email-masked]>
Date: Mon, 14 Nov 2005 13:50:47 +0200

Hi Jonathan!

I promised to clarify some xcap issues, first there are some nits in
<http://www1.ietf.org/mail-archive/web/simple/current/msg05883.html>. 

The current insert logic (xcap-08) is imo inconsistent when a mixed type
is used in the content model, i.e. if you have e.g.:
<root>
  <foo>
    <bar a="2"/>
  </foo>
</root>
and you insert <bar a="1"/> with 'root/foo/bar[1][@a="1"]'. so you end
up with:
<root>
  <foo>
    <bar a="1"/><bar a="2"/>
  </foo>
</root>   
skipping the first whitespace text node of <foo>. However, if <foo>'s
type is mixed (the previous example is valid for that type too) and if
the original doc had been
<root>
  <foo>
    text<bar a="2"/>
  </foo>
</root>
you would insert resulting with:
<root>
  <foo><bar a="1"/>
    text<bar a="2"/>
  </foo>
</root>
Now no skipping of the first text node. 

Anyway, I'm feeling somewhat dizzy about the whole insert logic, as you
always end up having some deficiency with it. So I'm now inclined to
prefer the logic where you insert a new element to the last possible
node position (where get(put(x))=x of course). That's because: 1.
appending as the last child is the most logical way, 2. that's the way
typical libraries do anyway, 3. it's consistent with the 07-version, 4.
it leads to the shortest text in the spec, 5. if you insert with
"root/node" or "root/node[1]" and there's no <node> within <root>, the
position is the same in both cases. Probably some other reasons, but
I'll prefer KISS here (as almost always).

The second issue that I was unable to clearly state, was about patching.
With XPath you can't locate e.g. xml entities from the xml prologue of
the document, e.g. I've used xml entities with patch-ops: <!ENTITY
ncname  "[^:\I][^:\C]*">. So if the client updates an existing document
so that prologue changes, it is not possible to patch that with XPath
semantics, so you have to download the whole document again. So this
influences xcap-diff, where it should be clearly expressed to the client
that reloading is necessary. So my thought was to add e.g. some "state"
attribute info to xcap-diff: "created", "modified" (==prologue changed),
"deleted". 

thanks,
Jari 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple