Re: XInclude in XML Calabash

No problem for me/us


On 16/04/2016, 17:56, "Norman Walsh" <> wrote:

>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
>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

Received on Sunday, 17 April 2016 19:56:28 UTC