RE: [docbook-tc] DocBook Technical Committee Meeting Minutes: 20 April 2011

["Grosso, Paul" <pgrosso@ptc.com>]

> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net]
> Sent: Wednesday, 2011 April 20 14:26
> To: DocBook Technical Committee
> Cc: docbook@lists.oasis-open.org
> Subject: [docbook-tc] DocBook Technical Committee Meeting Minutes: 20
> April 2011
> 
> DocBook Technical Committee Meeting Minutes: 20 April 2011
> =============================================================

> 9.  Transclusion in DocBook.
> 
> Jirka submitted an update [3] to this proposal adding
> Appendix D describing a simpler alternative proposal
> from Hussein Shafie.
> 
> Nancy was concerned that it did not allow overrides,
> which has become important in DITA, even though it
> complicates things.
> 
> Bob: we seem to be leaning toward a simplified
> transclusion mechanism.
> If we simplify, we need to remember that the
> original motivation was to overcome the limitations
> of XInclude, the primary one being ID duplication
> for repeated content.
> 
> Larry: Also, different implmentations of XInclude support
> different schemes, so not compatible between tools.

I assume "different schemes" refers to xpointer schemes,
that is, the value of the xinclude/@xpointer attribute.

But almost all examples in Jirka's writeup just use URIs
anyway.  And his full proposal does allow an xpointer 
attribute on the referencing element, but it's the same
attribute as on xinclude, so in what way is the issue
Larry raises above about xinclude any worse than what
the issue would be for a DocBook transclusion feature?
If for whatever reason implementations don't support
some xpointer schemes for xinclude/@xpointer, why would
those implementations be more likely to support those
same xpointer schemes for DocBook's @xpointer?  And
insofar as one can write a DocBook transclusion processor
in XSLT as Jirka has done, why couldn't the same thing
be done for xinclude?

paul