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

["Tony Self" <tself@hyperwrite.com>]

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/39557/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
>
>