Hussein Shafie <[hidden email]> writes:
> The new XInclude Working Draft:
> looks good. It attempts to fix some of the problems of XInclude 1.0:
The intent, and I'll try to clarify this in the next draft, is that
> 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.
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.
I have to say, I'm not sure I ever even thought of doing this with
>  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)"/>
Right. That's why you need a second step to do the right thing.
> </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"):
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.
Be seeing you,
Norman Walsh <[hidden email]> | All professional men are
http://www.oasis-open.org/docbook/ | handicapped by not being allowed
Chair, DocBook Technical Committee | to ignore things which are
| useless.-- Goethe
attachment0 (192 bytes) Download Attachment
|Free forum by Nabble||Edit this page|