RE: [dita-help] Layering in Help Systems

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

Thanks, Scott.

When I was reading your comments about "the ability to override the
treatment of specific cases", I immediately thought of the outputclass
attribute as a mechanism. This would also conform to your ideal of "minimal
(or no) additional structural elements". But then you raised the idea of a
"uacontrol" attribute, which is a very interesting idea. But do you think
such an attribute would be doing the same job as outputclass?

In DITA 1.2, there is some sort of sibling selection mechanism for
conreffing, so that a subset of steps, for example, can be used as a single
conref. Is anyone in the subcommittee sufficiently au fait with this feature
to know whether it could be used for the "help-group" treatment mentioned by
Scott?

I've added a new page to the DITA Help Wiki at:
http://wiki.oasis-open.org/dita/DITA_Help_Help-Specific_Formatting

with a table where we can build a list of Help features and how they might
be implemented. Please, everyone, feel free to contribute to the table! (By
the way, when using XML code, put a space before the code phrase, otherwise
the Wiki software will treat it as HTML markup.)

Tony



-----Original Message-----
From: Scott Prentice [mailto:sp@leximation.com] 
Sent: Wednesday, 7 January 2009 4:45 AM
Cc: dita-help@lists.oasis-open.org
Subject: Re: [dita-help] Layering in Help Systems

Yes .. Happy New Year to you all!

I think that it would be nice to be able to handle all elements of a 
specific type with a specified treatment .. however, I think that we'd 
also need the ability to override that treatment for specific cases as 
well as being able to apply that treatment in an ad-hoc manner. I tend 
to think of these Help-specific treatments to ranges of content as 
"functional formatting" .. as opposed to just applying some visual 
properties, we need to be able to apply some sort of event-driven 
properties and formatting.

I'd like to think that this could be done with minimal (or no) 
additional structural elements. Perhaps this can be thought of as a 
special type of filtering, and we can add a "uacontrol" attribute to all 
elements that would allow ad-hoc application of this user assistance 
formatting as well as supporting the overriding of a global setting. 
Perhaps we could add a prolog section that allowed the user to define 
settings that could be applied to an entire topic (as well as child 
topics), and a similar topicmeta or bookmeta section that would apply 
settings to all topics within a map.

It seems like we need to come up with a list of all possible 
Help-specific formatting that we'd like to be able to manage, then see 
what type of mechanism would be needed to control that formatting.

The only situation that I can think of off hand that might require an 
additional element would be some way to group sibling elements. 
Although, I really don't like the idea of introducing a special 
"help-group" element whose only purpose is to apply some special 
Help-specific treatment to a range of elements. It seems like you'd be 
able to group these elements using an existing element. One of the core 
aspects of DITA is modularity and reuse, and if we do things to craft 
the content in a very Help-specific manner, we would be working against 
that premise.

Cheers!

...scott