[Norman Walsh] Re: XInclude 1.1

Hussein Shafie <hussein@xmlmind.com> writes:
> The new XInclude Working Draft:
>
> http://www.w3.org/TR/xinclude-11/
>
> looks good. It attempts to fix some of the problems of XInclude 1.0:

Thanks.

> 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. ---
>
> [1] "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
and such.

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.

> [2] There are still duplicate ID validation errors in cases such as
> the following one:
>
> --- <?xml version='1.0'?> <document
> xmlns:xi="http://www.w3.org/2001/XInclude"
> 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
xml:id.

>
> </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 [1] and [2] 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,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | 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