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 -- ▾). 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.
74 messages in org.oasis-open.lists.docbookRe: [docbook] Add topic element to Do...
.pgp