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 Implicit Title-only Topics


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

<perennial-rant>
It feels like we are making the same mistakes with DITA that
were made with SGML (and HyTime and XLink?); we may make it
so powerful that few will implement it and no one will be
able to use it, and it will be dropped in favor of something 
simpler.  I'd like to avoid that.
</perennial-rant>

paul

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Tuesday, 2009 March 31 13:08
> To: Grosso, Paul; dita
> Subject: Re: [dita] ITEM: Cross-references to Topicheads and 
> Implicit Title-only Topics
> 
> On 3/31/09 11:09 AM, "Grosso, Paul" <pgrosso@ptc.com> wrote:
> 
> > I'm not able to follow all this.  It's sure sounding complicated.
> > 
> > We're not talking about adding anything to DITA 1.2 here, are we?
> 
> Not from a markup standpoint. We're simply clarifying behavior already
> arguably implicit in existing features.
> 
> In particular, I'm proposing that if a topichead has an 
> effective  chunk
> value of "to-content" that processors are obligated to behave 
> as though a
> title-only topic exists whose title is the navtitle of the 
> topichead. In
> addition, if that topichead happens to have a crossref to it, that the
> effective target of the crossref is the implicit title-only topic.
> 
> If a topichead does not have an effective value of 
> "to-content" for chunk
> then processors *must not* imply title-only topics (that is, 
> the implication
> of title-only topics for topicheads must be entirely under 
> author control in
> order to avoid surprising differences in behavior from 
> different processors
> for the same map).
> 
> We're also saying that normal copy-to= semantics apply, such that the
> implicit topic, if it results in a unique storage object in 
> the rendition
> (e.g., an HTML file), will be named according to the existing 
> rules for
> copy-to.
> 
> For example, given this topichead in a map:
> 
> <topichead
>   key="about-this-book"
>   chunk="to-content select-topic"
>   copy-to="about-this-book"
> >
>   <navtitle>About This Book</navtitle>
> </topichead>
> 
> The HTML rendition will result in a generated topic 
> "about-this-book.html".
> 
> Likewise, given this xref in a topic used from the map containing this
> topichead:
> 
> <xref keyref="about-this-book"/>
> 
> The effective target of the xref in the HTML rendition will be the
> about-this-book.html HTML file.
> 
> Likewise, in a PDF rendering, there would be a body division 
> with the title
> "About This Book" and the xref would point to it in the PDF rendering.
> 
> I'm also suggesting that an xref to a topicref *has always* 
> represented an
> indirect reference from the xref to the ultimate target of 
> the topicref. The
> DITA 1.1 spec was not explicit on this matter, but given the 
> existence of
> keyref= in DITA 1.2 and our explicit statement that keyrefs 
> to topicrefs are
> indirect references to the ultimate target of the topicref, 
> then, by the
> principle that form of address doesn't change the semantic of 
> a link, then
> href= pointers to topicrefs are also indirections to the 
> topics pointed to
> by those topicrefs (because *any* type of pointer to a 
> topicref must be an
> indirection if any specific type of pointer is an indirection).
> 
> 
> Cheers,
> 
> Eliot
>  
> 
> ----
> 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]