RE: [dita] ITEM: Cross-references to Topicheads and Implicit Title-only

Eliot wrote:

> The only thing my proposal adds is a requirement that processors

> implement chunk= semantics for topicheads.

And the DITA 1.1 Architecture Spec. has this statement that I don't think is changing in DITA 1.2:

Chunking is necessarily output transformation specific with chunked output required for some and not supported for other types of output. Chunking is also implementation specific with some implementations supporting some, but not all, chunking methods, or adding new implementation specific chunking methods to the standard methods described in this specification.

Given this, it is hard to add a requirement that processors do anything in particular with @chunk. I guess you might say that if a processor implements chunking that it SHOULD (but is NOT REQUIRED) to chunk topichead elements in the same way that topicref and other topicref specializations that include a navtitle are chunked. But since this is implied elsewhere, it might be simpler and clearer just to be silent about topicheads and chunking.

Does this all just come back to what Michael has been saying over and over for a long time, that there should be no special treatment of topichead (or topicgroup) as elements in their own right, but all topicref and topicref specializations including topichead (and topicgroup) should be treated the same way depending on the properties associated with the element:

1. @format=”ditamap” and @href gives map reference semantics, no addition to the output hierarchy

2. Neither @href nor navtitle specified gives topic group semantics, no addition to the output hierarchy

3. navtitle specified, but no @href value gives topic head semantics, adds to output hierarchy

4. @href and possibly navtitle specified gives topic reference semantics, adds to output hierarchy

If this is what we are saying, can we just say this and not say anything specific about how topichead is related to chunking, keyref, xref, copy-to, or anything else? It seems confusing to single out topichead and a few features for specific treatment, when we are silent about the many other combinations that are possible.

We certainly need to avoid using the words MUST or REQUIRED for things that were not requirements before.

Is the DITA 1.2 specification going to say something explicit about xrefs that reference maps or elements within a map? I don’t think the DITA 1.1 spec. said anything about that. And unless there was previous discussion and an approved proposal about this for DITA 1.2, I think it is pretty late in the process to add anything as strong as a requirement. I guess you might add something that said “MAY” or possibly even “SHOULD (but is NOT REQUIRED)”.

-Jeff

> -----Original Message-----

> From: Eliot Kimber [mailto:ekimber@reallysi.com]

> Sent: Tuesday, March 31, 2009 3:12 PM

> To: Grosso, Paul; dita

> Subject: Re: [dita] ITEM: Cross-references to Topicheads and Implicit

> Title-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>

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail. Follow this link to all your TCs in OASIS at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

dita message