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 4:05 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

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

That's a good point--I hadn't remembered this particular statement, but it
does, I agree, imply that the strongest thing we could say is SHOULD.

I don't think chunking of topicheads is implied anywhere else, which is why
I think an explicit statement is warranted. But I could be wrong.
> 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:

That has always been my intent: I never meant my use of the term "topichead"
to mean "the specialization of topicref named 'topichead'" but simply "a
topicref that does not have an href= or keyref= and does have a navigation

I agree with Michael that in all discussion of core semantics for the
topicref base type, what matters is the configuration of properties
exhibited, not the specialization that might be used.

Or said another way: DITA should have always had a base type named something
like "MapHierarchyItem" from which are then specialized the types
<topicref>, <topichead>, and <topicgroup>, which each have distinct, and
exclusive, configurations of required attributes and serve as convenience
specializations that do not have unique semantics of their own.

But we don't have that (and can't add it in 1.x) so we always have to say
"by 'topichead' I mean "a topicref with no href= and a navtitle".

Anyway, that's what I mean.
> 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)".

It does via keyref: it says that any topic-content element that points to a
topicref that itself addresses a topic is a reference to the topic, not the

My assertion is that since it is true for keyref, it *must* be true for
href= as well. Further I'm saying that if it's true for href= in DITA 1.2
*it was always true for href=*. But since the DITA spec was silent on the
matter before 1.2 it was at least arguably ambiguous what it meant to xref
to a topicref (of any configuration).

Remember too that DITA 1.2 is adding new feature, the ability to point from
non-xref elements to topicrefs (via keyref) but it always had the ability to
use xref to point to map components. So the addition of keyref doesn't
actually change anything about either the ability to create
topic-element-to-map-element relationships.

It might also be useful to say "the processing implications for xrefs to map
components other than topicref or map elements is not defined."

And I'm not so sure about map elements, since it's not clear to me what it
would mean to have an xref to a map that is not the root map (e.g., that
does not represent an atomic unit of publication).

A cross reference to a root map is, I think, at least potentially clear, in
that I would take it as a reference to the entire publication the map
represents (e.g., a citation to a document as published). But I don't think
the DITA spec currently says anything about this case either.

But would it make sense to have a cross reference to a reltable? Not sure,
but my initial instinct is to say no, it's not sensible.



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]