RE: [dita-help] Help Features in DITA 1.3

A couple of very interesting ideas there that we hadn't thought of (the
'trivial map' and a 1.3 processing map) & which I will pass along to the
BusDocs SC forthwith.

The treatment of <table> is one of the gripes I have with 1.0
architecture decisions. I would have had a <list> element from which
<ol>, <ul>, and <table> were specialized, and both <li> and <row> would
be specialized from the same element. (This based on prior work in
discourse analysis, in which a text is transformed to a table with all
members of a semantic equivalence class in a column.) But that isn't
changing any time soon !->

	/B

> -----Original Message-----
> From: Alan Houser [mailto:] 
> Sent: Thursday, December 09, 2010 11:32 PM
> To: 
> Cc: Bruce Nevin (bnevin)
> Subject: Re: [dita-help] Help Features in DITA 1.3
> 
> This tangentially raises a point that has always troubled me 
> about semantic markup and the separation of content and 
> format (or content and behavior). Sometimes the intended 
> rendering of a chunk of content is really, really important. 
> Several such requirements exist in the online help domain. It 
> may be easier to specify an associated behavior, with the 
> option of ignoring that behavior if so desired, than to keep 
> the source semantically "pure" and go through hoops to 
> associate behaviors with content chunks through indirection, 
> annotation, post-processing, or other means.
> 
> Table markup has always mixed semantics and presentation. I 
> think it's appropriate to do so in other limited 
> circumstances as well.
> 
> Having said that, with DITA 1.2, we have a de-facto two-way 
> association between a topic and a map. (A topic that uses 
> keyrefs must be associated with a map at creation time; I 
> believe some authoring tools allow you to specify a keyspace 
> for a topic before it is actually referenced from a map).
> 
> I'm o.k. with putting behaviors in maps. In the case of 
> ditabase topics, can't a map include a topicref to a ditabase 
> collection? Perhaps ditabase documents could be associate 
> with a trivial map, which would define keys, define other 
> behaviors, and perhaps have a single topicref to the ditabase 
> collection. Or perhaps DITA 1.3 could support a looser 
> connection between maps and topics. Like a ditaval file, a 
> map could be specified at processing time (to define keys and 
> OH-related behaviors), even though the map does not reference 
> the ditabase collection.
> 
> Just thinking out loud. Apologies if I've missed anything.
> 
> -Alan
> ---
> 
> Alan Houser, President
> Group Wellesley, Inc.
> 412-363-3481
> www.groupwellesley.com
> 
> 
> On 12/9/2010 11:00 AM, Bruce Nevin (bnevin) wrote:
> > There's precedent, and a philosophical basis, for putting 
> > publication-specific stuff in the map and retaining the 
> > output-neutrality of topics.
> >
> > We on the BusDocs SC have been wrestling with user demand for a 
> > simplified authoring environment that presents topics 
> aggregated as a 
> > single monolithic document. If we use ditabase for that, we 
> face some 
> > thorny issues of persisting features of the map that are 
> not supported 
> > in ditabase (grouping elements, topichead, anchor/anchorref, 
> > attributes in topicmeta, and the like). What if topics are moved, 
> > deleted, and inserted? Are embedded topics round tripped as nested 
> > topicref or as references to submaps?
> >
> > OLH of course is nonlinear (except for its ToC) but it is often 
> > single-sourced with conventional, linear document 
> renditions, and some 
> > of the user base may have the same preference for a more 
> traditional 
> > authoring environment without a map editor.
> >
> > So by a roundabout way comes the suggestion that any help-specific 
> > stuff that we put in the map may need to be thought about 
> in ditabase as well.
> >
> > 	/B
>