OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-help message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita-help] Layering in Help Systems

Hi Tony...

I was actually thinking that the "uacontrol" was more like the filtering 
attributes in that there could be multiple values in that attribute that 
would cause different actions to be applied. It seems that there may be 
some conflict between help-specific formatting and formatting for other 
output types, so I'd probably not want to think that outputclass would 
be available for this purpose.

Perhaps in (prolog|topicmeta|bookmeta) there's an element called "ua" 
and within that are some elements that allow configuration of this UA 
formatting. Perhaps there's a "collapsed-tags" element (ignore the names 
for now, just go with the idea) that contains "tag" elements, which have 
two children .. a name element (for specifying the element name) and a 
label element (for defining the clickable label). This defines all of 
the elements that should be rendered as a collapsed region with a 
clickable label. The "uacontrol" attribute might allow certain flags 
that would override and/or augment this collapsed formatting .. perhaps 
"expanded" which would set the default state to be expanded, or 
"nocollapse" to force a particular element to not receive the 
collapsible formatting.

Just some random thoughts .. I think we need to start with the list of 
UA features to support, then it'll be clearer as to how best they can be 

I'll take a look at your wiki page .. hopefully tomorrow.



Tony Self wrote:
> 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
> ---------------------------------------------------------------------
> 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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]