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