Review of DocBook transclusion proposal

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

Per my action, I reviewed Jirka's transclusion proposal at
http://lists.oasis-open.org/archives/docbook-tc/201007/msg00041.html

I note that the document agrees that xinclude can handle most
of the use cases except transclusion within attribute values
(which the proposal also doesn't handle) and the issue of
id-fixup.  I don't understand how the proposal handles UC-6
any better than xinclude does.

So I wonder if it's worth defining a new mechanism rather 
than using xinclude and requiring some id-fixup. 

Assuming we do go with something like the proposal, I could
imagine someone wanting to implement it using xinclude under
the covers.  

Both for that reason and more generally, I wonder why the
proposal says that xml:lang fixup should not occur, especially
given that xml:base fixup does need to occur.

I assume the comments in the proposal about profiling
(effectivity) really have nothing specific to do with the
proposal; rather standard DocBook profiling would occur
after transclusion, and this proposal isn't suggesting
any changes with respect to profiling.  Correct me if
I'm wrong.

ID fixup is the most complex part of things, but I'm
pretty sure we don't need quite so many options.  With all 
those options, we may not get as many implementations, and 
it's more likely the implementations we do get may have bugs
or incompatibilities.  I think we should just say that a 
transclusion implementation needs to make all ids unique 
and needs to fix up references, and leave most of the 
details to the implementation.

But fixing up references is still the complicated part.
Clearly an id/idref link within a single piece of transcluded
content should continue to work after id-uniquification.  As
far as a link between two things that didn't start out (before
transclusion) in the same piece of content, I'm not sure 
what it means in all cases.  If someone has an idref in
their document to an id in something they are transcluding
and they transclude it more than once, what do they want?
I'm not happy with either the near or global linkscope
definition in the proposal, as they both seem like a hack.
The only reasonable interpretation is a one-to-many link,
but I don't know if we want to get into that.  I'm not
sure what to think here.

Regarding:

 transclusions should be added into core DocBook. I don't
 think that making them separate XML transclusion standard
 is viable approach. Transclusion processor has to know which
 attributes are of ID/IDREF type for each document type.
 History shown that generic standards relying on access to
 a schema are not successful.

Knowing which attributes are of ID/IDREF type is necessary
for many things (e.g., XPath's id() function), and this is
quite frequently done quite successfully for arbitrary 
doctypes using schemas or some other method.  I do not think
this is a good reason for hardwiring this proposal to DocBook,
and it is possible we'd get more implementation support if we
had a proposal that could add transclusion for other doctypes.
It sounds to me like one just has to specify the element names
used for the definitions, def, and ref (and maybe info) roles 
(and their attributes), and we can define a doctype-agnostic
transclusion feature.  But maybe this is an implementation
detail (i.e., some implementors will make it general but
others won't) and doesn't really affect the DocBook TC
proposal.

paul