[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:arh@groupwellesley.com] > Sent: Thursday, December 09, 2010 11:32 PM > To: dita-help@lists.oasis-open.org > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]