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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: Re: [docbook] Add topic element to DocBook?



On Oct 27, 2006, at 12:36 PM, Rowland, Larry wrote:

> Aren't all of the DocBook elements you identified that have semantic
> structures block elements?

They are, but I don't see what difference that makes...


> I really like the task element that was added to DocBook, since it  
> does
> exactly what you described -- provides a richer semantic  
> environment for
> grouping the information related to a procedure -- I have had to do  
> the same
> thing repeatedly in documenting products.  In terms of processing
> prerequisites and such differently, couldn't the role or remap  
> attributes
> carry that type of instruction?

Sure, role or remaps could convey processing information.  But it  
would be a massive kludge.

Suppose an author has a two paras of prereq information marked with  
the prereq role and then decides to split the first para into two.   
The writer, expecting the the split to work like every other para,  
simply presses return where the para should split.  Now we end up with:

<para role="taskprereq"></para>
<para></para>
<para role="taskprereq"></para>

That would add tons of headaches into the processing stream.

Also, how would we make sure that the role="taskprereq" is only used  
in tasks?  How can we make sure that the prereqs are only before a  
procedure and not after?

Role attributes in this context are completely antithetical to  
structured content.



> I guess I am concerned about processing expectations.  I want a  
> task to be
> visually distinct, which is easy when it is a block element.  Does  
> a sect2
> equivalent task look like a sect3 equivalent task, or do the  
> headings take
> on the appearance of the equivalent of a section at the same level  
> in the
> hierarchy?  If so, haven't I lost the visual cue that this is a task.

Does it matter?

In our environment, a task title looks just like section title,  
except that we generate a glyph (a triangle -- &dtrif;).  So, if a  
task occurs in a sect1, then it's formatted as a sect2 would be. If a  
task occurs in sect2, it would be formatted as a sect3.

But if you wanted a task to format differently, couldn't you do that  
regardless of where it appears in the hierarchy?  That's a processing  
expectation that I think should be left to the implementors.



Steven Cogorno
Sun Microsystems




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