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