- From: Nic Gibson <nicg@corbas.co.uk>
- Date: Sun, 17 Apr 2016 19:55:54 +0000
- To: XProc Dev <xproc-dev@w3.org>
No problem for me/us nic On 16/04/2016, 17:56, "Norman Walsh" <ndw@nwalsh.com> wrote: >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 Sunday, 17 April 2016 19:56:28 UTC