> However, the attribute copying feature as described in the Working
> Draft seems too restrictive to be really useful.
> Excerpts from the Working Draft: --- 4.3 Attribute Copying when
> processing XML ... Any namespace qualified attribute that appears on
> the xi:include element will be copied onto every top-level included
> item that is an element information item.
> If the element information item already has an attribute with the same
> qualified name, its value is changed to the value specified on the
> xi:include element. ---
>  "Any namespace qualified attribute" poses a problem as most
> schemas use attributes which are not namespace qualified. In practice,
> this makes attribute copying as described above useful only for
> attribute xml:id.
The intent, and I'll try to clarify this in the next draft, is that
you'd use additional, namespace qualified attributes to pass along
information that a subsequent step would use to resolve duplicate IDs
There are two problems:
1. Copying non-namespace qualified attributes means that you can't
pass attributes named parse and href, etc. And it means if XInclude
1.2 adds a "range" attribute, then that may collide with existing
documents. Using namespaces avoids this problem.
2. There's no strategy for resolving ID/IDREF errors that is the
single, right answer. The DocBook transclusion requirements document
lists half a dozen possibilities. By using your own attributes, you
can identify (to a downstream step) what policies you want to use in
each XInclude case.
>  There are still duplicate ID validation errors in cases such as
> the following one:
> --- <?xml version='1.0'?> <document
> xmlns:eg="http://example.org/namespace/example"> <p>This example
> includes a “definition” paragraph from some document twice using
> attribute copying.</p>
> <xi:include href="src.xml" xpointer="element(def)"/>
> <xi:include xml:id="def2" href="src.xml" xpointer="element(def)"/>
I have to say, I'm not sure I ever even thought of doing this with
> </document> ---
> where src.xml is:
> --- <document> <para>Some paragraph.</para> <para xml:id="def">Some
> <phrase xml:id="ph1">definition</phrase>.</para> <para>Some other
> paragraph.</para> </document> ---
> which gives us (duplicate ID error for xml:id="ph1"):
Right. That's why you need a second step to do the right thing.
The goal of attribute copying in XInclude 1.1 is to provide a
mechanism for some downstream process to be able to know where the
XInclude boundaries occurred.
Today, you simply can't tell so you have no hope of fixing things.
> I don't know if it is possible to solve problems  and  while
> keeping the XInclude spec 1.1 as simple and as generic as it currently
> is. However, I would really like to see these problems solved
> elegantly because if this is the case, then may be DocBook 5.1 would
> not need to have its own, DocBook specific, transclusion mechanism:
My goal is to build, as a separate spec, a vocabulary of extension
attributes to use in, for example an XProc pipeline, to provide
flavors of ID/IDREF fixup.