XInclude 1.1 LC Disposition of Comments

attached mail follows:

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

attached mail follows:

"Bob Stayton" <bobs@sagehill.net> writes:
> Hi Norm,
> I read through the new spec and it looks good.  I have just a couple of comments.
>
> 1. The first example in C.6 uses frigid="line=2,6". Unless you are
> introducing a refrigerator identification system, I think that should
> be fragid. 8^)

Thanks. Paul noticed that bug moments after the last call draft was
officially published. Because that's always the way it is. I've
already fixed the sources, it'll be fragid next time around :-)

> It also says "There are four of them", but I think lines="2,6" is
> inclusive, so that would be five lines, no? The output example seems
> to include the fifth blank line that puts </pre> on its own line.

No, per RFC5147, I think that's lines 3, 4, 5, and 6 of the file.
I think the newline is part of line 6.

I'd be curious if you check RFC5147 and see if you think I'm
misinterpreting it.

> 2. In C.7, the example of attribute copying, I would like to see a
> second example that replaces xml:id. I presume that works even when
> the xpointer is using the xml:id in the source file to fetch the
> content.

Ok. I can add another example.

> Regarding xml:id fixup, this feature only applies to the top-level
> included element. If there are duplicate xml:ids in its descendants,
> then further fixup will be required after inclusion, right?

It fixes all the references properties, but if you really have
duplicate IDs and such, you'll need to do some post-processing to
actually get the results you want.

> 3. This document does not address any improvements to xpointer. I
> still use xsltproc for its implementation of the xpointer() scheme of
> xpointer, but that scheme never became a standard. What is the status
> of using some kind of xpath syntax in xpointer?

There's an xpath() scheme and it's pretty widely supported, I believe.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Society is immoral and immortal; it can
http://nwalsh.com/            | afford to commit any kind of folly, and
                              | indulge in any kind of vice; it cannot
                              | be killed, and the fragments that
                              | survive can always laugh at the
                              | dead.--Henry Adams

Bob,

Thank you for your comment on the XML Core WG's Last Call draft of
XML Inclusions (XInclude) Version 1.1 (January 2013) [1] recorded at
http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2013May/0000
(having been forwarded there from the DocBook list by Norm).

Note also Norm's reply recorded at
http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/2013May/0001

Please see the latest editor's draft at
http://www.w3.org/XML/2013/07/xinclude-11/
and/or the diff-marked version at
http://www.w3.org/XML/2013/07/xinclude-11/diff.html

Please reply to www-xml-xinclude-comments@w3.org indicating your
acceptance of this disposition of your comments or explaining any
remaining concerns you may have.

Paul Grosso
for the XML Core WG

[1] http://www.w3.org/TR/2013/WD-xinclude-11-20130115/