The SIP for Instant Messaging and Presence Leveraging Extensions Working Group has submitted RFC 5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors to the IETF. "Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove> directives a set of patches can then be applied to update an existing XML document. "
This reminds me a lot of XQuery Update, XUpdate, and XProc. I'm not sure exactly what this brings to the table, but it may be simpler and easier to comprehend. It would help if there were some clear use cases this was intended to solve.
It's not clear who worked on this, but they're some pretty fundamental mistakes throughout the spec. Namespace handling looks seriously broken, but maybe that's fixable. Character set handling is definitely broken. ID handling is broken.
Perhaps future drafts will improve. Someone remind me: is an IETF spec at this stage fixable or not? Oh damn: looks like it's not. This is what happens when amateurs build on top of specs they don't understand. There may be the nugget of a good idea here, but the implementation is crippled by bad design decisions and misunderstanding of XML. Sadly XML is not as simple as it's supposed to be, or as simple as it appears. That goes double for XPath and triple for namespaces. If you don't live and breathe this stuff, you need to work with someone who does before publishing new specs and tools. Sadly it doesn't look like the SIP for Instant Messaging and Presence Leveraging Extensions Working Group did that, and consequently they produced an incoherent, contradictory, nearly unimplementable spec. :-(
