RE: [docbook-apps] oXygen 9 beta with WYSIWYG-like editingsupportforDocBook

[Ron Catterall <ron@catterall.net>]

I have thoroughly enjoyed reading the last two dozen or so emails on 
this topic.  I'm late joining in, but that's just one of the problems 
of living a long way west of Greenwich.

It seems to me that there are two distinct problems.

1. Is Oxygen corrupting the pure XML distinction between structure 
and presentation by introducing 'bold' and 'italic' into XML when 
what they should be doing is offering different ways of emphasizing 
text.  The Oxygen solution is no different to what I do when I use 
<emphasis role="bold"> and define how to present 'bold' in my 
customization layer.  Unfortunately 'bold' and 'italic' are emotive 
terms which carry presentation meaning - but doesn't <para> also do 
this as well, we all know roughly what a paragraph looks like. 
Anyway, if you use Oxygen 9 you don't have to switch to author view 
if you prefer typing tags.

2. Is Docbook lacking in structural elements?  Particularly in 
different types of emphasis.  This I think is the real problem.  I 
think we can all agree that a block element such as <chapter> is a 
structural element, so is a <section> and a <para> etc.  When we come 
to in-line elements, docbook offers us two choices which seem to 
imply presentation <quote> (put it in quotes) and <emphasis> (make it 
stand out from running text in some way.)  The trouble is that for 
some in-line elements the distinction between structural elements and 
presentation directives is less clear:

If I say "I want this bit in italics" then that is mixing structure 
and presentation (a la Word).
If I say "I want this bit emphasized" then that is a structural 
element, and how I (or docbook) choose to present this 'bit' is 
determined in a style sheet.

But what if I want different ways (or levels) of emphasis.

In my work when I use <emphasis role="bold"> it is my customization 
layer to the docbook style sheet which determines how to present 
'bold', it happens to be 'B', but it could be 'I', 'U', or anything 
else.  It is using the term 'bold' which introduces confusion; 
everyone knows what bold text looks like.  I presume this is why Norm 
chose the term <emphasis>, to get away from the 'B', 'I', 'U' 
syndrome.

The fact is that writers DO want to emphasize 'bits' in different 
ways.  What is needed in docbook is a set of different ways to 
emphasize 'bits', and to be semantically acceptable the element names 
should not carry connotations such as 'bold'.  Someone suggested 
<emphasis role="5"> - but then I would have to define that '5' means 
'underline etc. (or remember it if it was a default action.)

Perhaps what we should do first is try and define all the different 
ways in which authors want to write structural 'bits' which 
distinguishe them from normal running text

The docbook <para> element already offers a very wide selection of 
elements which all have clear structural meaning, abbrev, acronym, 
address, author, caution, phrase  etc. etc., and how these are 
presented is defined in the style sheets.  The odd one out seem to be 
<emphasis> which seems to imply considerable presentation of this 
structural unit.  Of course subscript and superscript certainly imply 
presentation very strongly.

The XML and Docbook point is that all these can be re-defined to be 
presented in any way you like (even superscript!)

However, there does seem to be a very real need for distinguishing 
between different types of emphasis.  The knee-jerk reaction is that 
you can't use terms like 'bold' and 'italic' in XML: that is heresy. 
Does the answer to all this lie in Roget's Thesaurus?

Could we accept <emphasis role="xxx">
where 'xxx' is ...........?

-- 
Ron Catterall, Phd, DSc			        	email: 
ron@catterall.net
Prolongacion de Hidalgo 140				http://catterall.net/
San Felipe del Agua					tel: +52 951 520 1821
Oaxaca      68020	Mexico				fax: +1 530 348 8309