OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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....



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]