[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [docbook-tc] request for conref
-----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Wednesday, July 15, 2009 5:40 PM To: Gershon Joseph (gerjosep); Bob Stayton Subject: Re: [docbook-tc] request for conref Looks like I can't post to the DocBook list. Can one you forward my note? Thanks, Eliot On 7/15/09 9:37 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > On 7/15/09 9:16 AM, "Gershon Joseph (gerjosep)" <gerjosep@cisco.com> wrote: > >> Personally I'd vote against conrefs and instead wait for XInclude and >> XPointer to mature. The W3C removed conrefs from XML because >> processing them was deemed complex. IBM already had conref processing >> in their SGML tools and therefore brought conref back in when they invented DITA. >> Conrefs have limitations, which leads to almost as much headache in >> terms of maintenance as file entities generate. So now DITA 1.2 will >> be introducing key referencing and content key referencing. This >> latter approach offers amazing flexibility for reuse and is very lean >> on maintenance overhead. I'd be willing to discuss this during the >> meeting today if the TC is interested. > > Gershon's point is very important: without some form of indirect > addressing, re-use of elements across publications and versions of a > given publication is essentially impossible in the general case. In > particular, it becomes impossible to have re-usable components that > have references to other components where the ultimate target of the > references is determined by the use context of the re-used component. > This is true for both topic-level reuse (in the DITA sense) and > element-level re-use (e.g., DITA conref). However, the existence of > conref compounds the problem because conref establishes element-level topic-to-topic dependencies. > > That is, if you have topic A that has a conref (or xref, the problem > is the > same) to topic B, then topic B must be used in *every map* that > includes topic A or topic A will be broken. > > But in many cases, you want the links from topic A to be to "the thing > that plays the role of topic B" in a particular map, not topic B > exclusively. This can only be done with some form of indirect > addressing where the binding of initial addresses (keys in DITA 1.2) > to ultimate targets is done in a specific use context, not in the initial reference. > > The W3C provides *no useful specification* for indirect addressing. I > proposed a simple indirection mechanism some years ago, submitted as a > note to the W3C, but as far as I know it got no interest. In short, > both XLink and XPointer, are, by themselves, not useful for authoring, > because they provide no indirect addressing mechanism. > > The DITA spec provides the keyref feature, which mostly solves the > problem, but it is limited in that it only enables indirection for > topic-level pointers--it doesn't enable redirecting an element-level > reference using one ID value to a different ID value (that is, you can > use keyrefs to point to individual elements indirectly, but all > potential target elements must have the same @id value). To use keyref > to address an element with a different ID than used in the initial > reference, you have to impose another layer of content reference > between a given key reference and a target element whose @id is not already what it needs to be, e.g.: > > For example, given this initial conref: > > <p conkeyref="somekey/foo"/> > > Where the intent is that in the current map the reference ultimately > resolves to a paragraph with the id "bar", you would need this keyref > and pair of <p> > elemetns: > > <map> > ... > <keydef keys="somekey" > href="indirection-topic.dita" >> > </map> > > Indirection-topic.dita: > > <topic id="topicid"> > <title>Indirections to Paragraphs</title> > <body> > <p id="foo" conref="#topicid/bar"/> > <p id="bar">This is the real paragraph</p> > </body> > </topic> > > Note that the keyref-based indirection is use-context-specific (that > is, a given map can change the key-to-resource binding) but the > conref-based indirection is invariant, which is why I put it all in one file. > > If DocBook does not provide some form of context-specific indirect > addressing, it would be irresponsible to add additional use-by-reference features. > > Cheers, > > Eliot > > > ---- > Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. > email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> > office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the > Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com > <http://www.reallysi.com> | http://blog.reallysi.com > <http://blog.reallysi.com> | www.rsuitecms.com > <http://www.rsuitecms.com> ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]