- From: Norman Walsh <ndw@nwalsh.com>
- Date: Sat, 16 Apr 2016 11:56:56 -0500
- To: XProc Dev <xproc-dev@w3.org>
- Message-ID: <87shyl331j.fsf@nwalsh.com>
So. I’m working through the XInclude 1.0/1.1 test suite and I’ve discovered that my implementation of XInclude is … buggy. Correct behavior for XInclude is that nested XInclude elements are expanded before evaluating fragids. So you can say <xi:include href="book.xml" xpointer="id(chapter1)"/> and it works even if the xml:id ‘chapter1’ is “behind” an xi:include element in book.xml. Fair enough. Unfortunately, fixing that bug has a consequence. Attribute types defined by DTD validation are lost in the expanded document. What this means in practice is that if you’re using DTD validation to assign ID types *and* using fragids to point to those IDs, it doesn’t work. (It does work if you name your ID attributes xml:id, which I hope you all do.) I don’t know how to fix this. It’s clear from the Saxonica API docs that NodeInfo.getSchemaType() doesn’t return types declared with DTD fragments. In theory, I could use NodeInfo.getTypeAnnotation() to find out, but the values I get back from that API don’t have the IS_DTD_TYPE bit set even when the type comes from the DTD. (All of this despite the fact that in the parsed document, before I copy it, the XPath id() function does work.) I suppose I should try construct a test case and report the bug but that’s not going to be useful today. And even if I could get the DTD type, it’s entirely unclear that I could construct a new tree with that type, so I’m not sure it’d help. On the whole, I think the best choice is to fix the “nested includes” bug and just accept that DTD-based ID attribute types won’t work. But how painful is that going to be for users, I wonder? Be seeing you, norm -- Norman Walsh Lead Engineer MarkLogic Corporation Phone: +1 512 761 6676 www.marklogic.com
Received on Saturday, 16 April 2016 16:57:29 UTC