W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > October 2011

TPAC topic: Extending XInclude

From: Grosso, Paul <pgrosso@ptc.com>
Date: Mon, 24 Oct 2011 12:54:17 -0400
Message-ID: <9B2DE9094C827E44988F5ADAA6A2C5DA03E1F9E0@HQ-MAIL9.ptcnet.ptc.com>
To: <public-xml-core-wg@w3.org>
Norm sent email on behalf of DocBook at
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Jul/0013
asking whether we want to consider extending Xinclude.

The key issue is that xincluding content can often cause
duplicate ids, and the question is whether we can define
some kind of fix up.

See http://docbook.org/docs/transclusion-requirements/#uc-5
for a use case.

See http://www.docbook.org/docs/transclusion/#d6e180 for
some DocBook proposals for id fixup.

A processor might be able to find ids and/or idrefs if xml:id
is used and/or there is a DTD/schema available, and even if 
that is the case, fixup would only work within the included
module, but is that partial case worth augmenting XInclude.

Liam suggests the only real solution is to do a transformation,
so he doesn't feel there is an XInclude solution.

Norm implemented Jirka's proposals using XSLT+XProc; see
http://norman.walsh.name/2011/10/03/transclusion

There was some follow up discussion as to what we might do; see
http://lists.w3.org/Archives/Public/public-xml-core-wg/2011Oct/thread.ht
ml#msg4

Paul said we could say that all attributes on the xinclude element
that are in the xinclude namespace should be copied to the "root"
included node(s).  That one thing would allow a follow up process
such as Norm's XSLT to do the necessary fixup.  If one did xinclude
processing after validation, one could give those extra attributes
defaults in the schema so that they didn't need to be authored.
Received on Monday, 24 October 2011 16:57:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 October 2011 16:57:21 GMT