Hi Liam, > Are you sure you're not thinking about XPath 1.0 and 2.0 here? The > changes for XML 1.0/1.1 are very small in terms of code, and there > are very few productions in the Spec grammar that are affected.
No. XPath 2.0 could easily be implemented in parallel with the existing XPath 1.0 implementation in libxml2, simply by adding a new "xpath2" module next to the existing "xpath" module. Application code could then use either API depending on their needs, and existing code using the xpath module would continue to work unchanged. Daniel says that implementing XML 1.1 would not require a fork of libxml2, and he should know. However, it would be one more source of complexity in the library, with associated testing burden and bug reports, for very little benefit. For example, I don't think that xmlReadFile() should be silently upgraded to parse XML 1.1 documents, as application code is not expecting to receive them, and would be faced with unexpected characters like  in the input, which they might already be using internally as sentinel values, knowing that they can never occur. A new options could be added, like XML_PARSER_XML11, which applications could pass to xmlReadFile() and other functions to indicate that they are happy to receive XML 1.1 documents. For applications to support it properly though, they would need to change their internal definition of whitespace to include NEL when the document that they are processing is an XML 1.1 document, which is frankly stupid. > Your argument would say no-one should ever implement anything new. Hardly. RELAX NG is new (well, it was new) and libxml2 has implemented it, without screwing up existing XML parsing. XPath 2.0 is new, and libxml2 could potentially support it, without breaking existing code or affecting existing support for XPath 1.0. XML 1.1 is not something new, so much as it is taking something that has been widely and interoperably implemented and breaking it in subtle ways. That's hardly logical. The only part of XML 1.1 that everyone agrees is reasonable is the support for more scripts in name characters, and avoiding explicitly specifying the set of UNICODE characters that can be used in names. So, why not introduce a fifth edition of XML 1.0 that expands the set of characters that may be used as name characters. This would be backwards compatible, as every well-formed XML 1.0 document would remain legal. It would allow the use of more scripts in XML markup, like Mongolian. Parsers could support it quite easily, and the change would be unlikely to confuse applications. Then admit that XML 1.1 was an experiment that failed, and has not achieved widespread interoperable implementation, and deprecate it. Best regards, Michael -- Print XML with Prince! http://www.princexml.com _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
