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

["Rowland, Larry" <larry.rowland@hp.com>]

Thanks Jirka, I like the proposal.

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.

  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.

  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.

The alternative to these three options was to pass through the ID on 
the referenced element and do nothing to IDs inside it, which was not
a problem if the block was only being included once, as opposed to
being included repeatedly in a document.

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.

Regards,
Larry

-----Original Message-----
From: Norman Walsh [mailto:ndw@nwalsh.com] 
Sent: Wednesday, July 21, 2010 9:25 AM
To: docbook-tc@lists.oasis-open.org
Subject: Re: [docbook-tc] Very rough proposal for DocBook transclusions

Jirka Kosek <jirka@kosek.cz> writes:
> I'm not sure if I will be able to send more complete proposal before telcon.

Thanks, Jirka. A few proofreading nits:

s/very bad, bud/very bad, but/
s/xpointer(id('product-name')/text())/xpath(id('product-name')/text())/

With respect to the DocBook Transclusion Proposal, I think I'd prefer
<ref name="product-name"/> to <ref>product-name</ref> just because it
will tend to minimize whitespace issues in the markup.

Do you have any ideas about what to do about the duplicate ID problem?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Science is like sex: sometimes
http://www.oasis-open.org/docbook/ | something useful comes out, but
Chair, DocBook Technical Committee | that is not the reason we are
                                   | doing it.--Richard Feynman