[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook-tc] Very rough proposal for DocBook transclusions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]