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

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

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

> -----Original Message-----
> From: Scott Prentice [mailto:sp10@leximation.com] 
> Sent: Tuesday, December 07, 2010 10:49 PM
> To: dita-help@lists.oasis-open.org
> Subject: Re: [dita-help] Help Features in DITA 1.3
> 
> Wild *and* crazy, eh?
> 
> That looks like it's certainly on the right track in my mind. 
> Let's spend more time looking at this and the ramifications.
> 
> Cheers!
> 
> ...scott
> 
> 
> 
> Tony Self wrote:
> > Hi Scott
> >
> > You earlier wrote that maybe you should review the spec, so 
> I thought I'd do so. 
> >
> > 
> http://www.oasis-open.org/apps/org/workgroup/dita-help/download.php/39
> > 557/dita-proposal-csh-win.html
> >
> > We are actually proposing a <ua-window> element in the map, 
> referenced by a key (the name attribute). Maybe we're 
> brilliant, not crazy?!
> >
> >
> > Tony Self
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Scott Prentice [mailto:sp10@leximation.com]
> > Sent: Wednesday, 8 December 2010 10:56 AM
> > To: tself@hyperwrite.com
> > Cc: dita-help@lists.oasis-open.org
> > Subject: Re: [dita-help] Help Features in DITA 1.3
> >
> > I guess I'm thinking of some structure that hangs off of 
> the map, like 
> > the keydef feature (or subjectScheme?) .. where you define the 
> > windowdefkey once, and reference the key when needed. This key 
> > definition could allow for multiple definitions that are used for 
> > different output types.
> >
> > I dunno .. just thinking.
> >
> > This structure could also be used for images and tables. It 
> lets you 
> > keep the values available for authors to set and manage, 
> but separates 
> > them from the immediate vicinity of the content (again .. I should 
> > locate the window definition spec).
> >
> > Crazy, perhaps?
> >
> > ...scott
> >
> >
> >
> > Tony Self wrote:
> >   
> >> Hi Scott
> >>
> >>   
> >>     
> >>>> some sort of key that maps to the actual window definition 
> >>>> elsewhere<<
> >>>>       
> >>>>         
> >> But where is "elsewhere"? Putting the definitions in the 
> ditaval would change the role of ditaval. (Maybe that's not a 
> bad thing, though.) In the publishing engine configuration files? 
> >>
> >> If the information is going to be stored somewhere (and 
> isn't ditaval now part of the OASIS DITA spec?), then 
> somewhere or other a good number of window properties have to 
> be stored. From the point of view of complexity, does it 
> matter whether this complexity is in the map or the ditaval 
> or the publishing config file?
> >>
> >> Tony Self
> >>
> >>
> >> -----Original Message-----
> >> From: Scott Prentice [mailto:sp10@leximation.com]
> >> Sent: Wednesday, 8 December 2010 10:03 AM
> >> To: tself@hyperwrite.com
> >> Cc: dita-help@lists.oasis-open.org
> >> Subject: Re: [dita-help] Help Features in DITA 1.3
> >>
> >> Could this be handled in an "outputclass" sort of way? The author 
> >> would specify some sort of key that maps to the actual window 
> >> definition elsewhere. My concern with window definitions is that 
> >> there are so many properties to define. I suppose that it could be 
> >> just a single attribute value where you specify the whole 
> string of 
> >> properties at once (I can't remember how the proposal was 
> set up), so 
> >> it's not much impact to support one additional attribute 
> (hmm, I should review the spec, eh?).
> >>
> >> However, I think that the examples of form embedded the 
> content that 
> >> you cite are actually quite problematic. It would be nice if image 
> >> sizing wasn't tied to the image element and tables would be much 
> >> nicer if their properties also weren't hard-coded. When 
> publishing to 
> >> various deliverables, these hard-coded values seldom 
> translate well. 
> >> It would be nice (OK, it would certainly add to the "complexity" 
> >> issue) if there was some sort of intermediate place to 
> define these 
> >> values. Perhaps set up some sort of key-based lookup 
> mechanism that 
> >> could be tied to ditaval filtering that let you specify the image 
> >> size and table properties (and window definitions), then 
> just reference that via the key.
> >>
> >> Granted .. the window definition issue probably isn't as bad as 
> >> tables and images, but it doesn't seem unlikely that you 
> might want 
> >> multiple window definitions for different types of online output.
> >>
> >> ...scott
> >>
> >>
> >>     
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the 
> OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >   
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>