[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] ITEM: Cross-references to Topicheads and ImplicitTitle-only Topics
On 3/31/09 1:40 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote: > I don't feel that this behavior is implicit in the > existing specs, and I fear there are a lot of complications > that we haven't had time to think through. > > Making all this processing explicit in the DITA 1.2 spec > makes things even more complicated, it will slow or delay > implementations, and those implementations are not likely > to be correct because this is so complicated that no one > understands it completely. > > The linking of chunking, xrefs, keyrefs, and all is a big > complication in terms of understanding any of those things > much less all of them together. We don't have time to figure > this all out for DITA 1.2 (and I suspect many users will > never figure it out). I think you're missing my point: I am explicitly *not* linking chunking, xrefs, and keyrefs. I'm simply saying that chunk=, an existing 1.1 feature, should apply to topicheads. Since chunk= and topicheads existed in 1.1, one can argue that *it always did* and I certainly have clients that used DITA as though it did and were surprised when existing implementations *didn't do it*. I'm essentially saying that the 1.1 spec's lack of statement on this subject is a 1.1 bug that we are fixing. Note that I am explicitly *not* saying, per Michael P's analysis, that an xref to a topichead, by itself, requires that the topichead be chunked. Michael correctly pointed out that that *would* be linking xref and chunking in an inappropriate way. I'm saying that if you, as map author, request a topic head to be chunked, it should be chunked, and having been chunked it is a valid target for references as though it were any other topicref to a topic. I'm also saying that, given that chunk= applies to topicheads, all the other features that apply to topicrefs *also apply* to chunked topic heads, just to make sure there's no question about it. But that doesn't change anything about the essential nature of keyref or xrefs (or any other reference to a topicref to a topic). I mention this only because there was a question on Michael P's part about whether or not xrefs that use keyref= should imply a different processing result from xrefs= that use href=. My response is that they should not. The only thing my proposal adds is a requirement that processors implement chunk= semantics for topicheads. It's hard to see how that, by itself, is an onerous complicating factor, especially relative to the inherent complexity in say conref= or keyref= or even basic map processing. I am not proposing anything that changes, in any way, the currently proposed semantics of keyref or xref. I'm simply clarifying the circumstances under which those semantics apply. I will also submit that without keyref and topicrefs as indirections, DITA is not useful for re-use scenarios for the simple reason that without both indirection and late-bound address resolution, it is impossible to have topics that are use-context independent. There are lots of existing XML and SGML authoring support systems that do this today, because they have to in order to satisfy business requirements inherent in the general problem of versioned hyperdocument management. But they are all proprietary and non-standard (except for those valiant few who both implemented and are still using a HyTime-based system:). All DITA is doing is attempting to standardize the syntax and associated semantics that people have been using for decades. As far as I can tell, DITA is just complicated enough to satisfy the known requirements. Unfortunately, the known requirements are inherently challenging. It is not possible for DITA to be any less complicated than it already is and still be useful for this very important use case. Having said I'll that, I will concede that, ultimately, my proposal for chunk= on topichead is a convenience that simply avoids the need to manually create the title-only topics that would otherwise be implied. But it seems silly to design a system this sophisticated and not have it provide an obvious convenience feature, especially when that feature does not materially affect the overall complexity of implementation. If we decided not to approve this feature, I would expect all DITA-aware editors to provide a "generate topics for topicheads" feature.... Cheers, E. ---- 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]