Re: [docbook-tc] Very rough proposal for DocBook transclusions

[Jirka Kosek <jirka@kosek.cz>]

Rowland, Larry wrote:

> We actually looked at the duplicate ID problem in the past and came up 
> with some solutions that depended on the user making a choice.  It does 
> require the user to know the content well enough to make the choice, 
> but for our environment that was not an unreasonable model.
> 
>   1) Simplest: Strip the ID from the referenced element.  This works
>      for the inline inclusion problem (that seems to be aimed at the
>      same use-case that entities were aimed at).  It may not work for
>      references to blocks of content, particularly if there are IDs 
>      inside the block.

Actually this shouldn't be necessary with my current proposal, because
<ref/> just pulls content of respective <def>...</def> and no ID is thus
carried with reference. This is different from using XInclude where ID
is copied.

>   2) Replace the ID of the referenced element with an ID provided on
>      the referencing element.  Again, this does not handle content
>      that has IDs included inside it, but it allows referencing the
>      element (like an admonition that needs to be repeated in a document
>      and also needs to have local references to it.  However, it can
>      be extended as described in the next option.  We indicated this
>      should be done by simple providing the ID on the referencing 
>      element.

Good point! I haven't thought about it but it seems very natural to use
xml:id on ref and propagate this ID to referenced content.

>   3) Replace the ID of the referenced element with an ID provided on
>      the referencing element AND use the new ID to prefix all IDs in
>      the transcluded block.  This means you also have to modify
>      references within the transcluded block that reference IDs in
>      the block, but not references to IDs outside the block.  Building 
>      the list of ID values that need to be processed and using it for 
>      processing the references proved challenging in XSLT 1.0, but 
>      straightforward in Java (I haven't tried in XSLT 2).  Once again, 
>      we chose to trigger this by having an ID on the referencing element.
>      If there are no IDs in the block, option 2 becomes a degenerate
>      case of this one.

I think that I will try to offer some more automagic ID mangling system
and some more user controlled system as you suggest. I think that it can
be implemented even in XSLT 1.0 but probably two passes over document
will be necessary.

> Both options 2 and 3 could be controlled by an attribute rather than by
> the presence of the ID, but the ID had to be provided anyway, so it
> didn't seem like too much of a stretch.  To deal with all four options
> it may be best to have an idpolicy attribute (probably with a default
> value of option 1, since inline use could become common as a replacement 
> for entities) to control this.  Not sure really, since policy 1 was in a 
> system that didn't have policy 2, so we ended up only having to deal with 
> either not modifying IDs or modifying them based on the ID attribute being 
> present.

Thanks for very useful insight. I will try to digest all input in next
draft.

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

OpenPGP digital signature