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

[Alan Houser <arh@groupwellesley.com>]

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