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