forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hargreaves <>
Subject Re: Documentv20 --> DocBook
Date Tue, 30 Dec 2003 11:47:52 GMT
On Tue, 2003-12-30 at 04:13, Ross Gardler wrote:
> Peter Hargreaves wrote:
> > On Mon, 2003-12-29 at 22:37, Ross Gardler wrote:
> > 
> >>Peter Hargreaves wrote:
> >>
> <snip what="XHTML isn;t about presentation"/>
> > Maybe the subset of XHTML adopted for Forrest could be a media
> > independent DTD like DocBook is.
> > 
> > What do you mean by presentational information? For me
> > <header>...</header> or <footer>...</footer> would be presentational
> > information because its meaning is about layout, and it assumes a media
> > type like paper that has headers and footers. However,
> > <title>...</title> is not presentational because its meaning is not
> > about layout. The skin or style sheet for the media called paper can
> > choose to put a title in the footer of the page or in the header.
> Agreed.
> Take a look at the comparison of XDoc and XHTML that Nicola Ken did 
> quite some time ago and I reposted at the start of this thread 
> (

> That is the subset we are proposing, it does not (or should not) include 
> any presentational information.
> >>>9) A central document type must therefore be very rich in its
> >>>description of document structure and meaning - without bias toward
> >>>media type.
> >>
> >>Quite the reverse. It should be as simple as possible, semantic meaning 
> >>has no place at the presentaional layer, it is only presentation that is 
> >>important.
> > 
> > If its simple then it will undermine the meaning of the original markup
> > - so the final presentation will be limited.
> Can you give an example of why the presentation will suffer?

If my source document has <article>, <chapter>, <section>, etc. I want
my skin to style them as those things. But wait, I think a penny has
dropped. See below...
> >>Can you give us a use case in which we need semantic meaning at the 
> >>intermediate stage in order to do anything *other* than effect how the 
> >>data is presented.
> > 
> > 
> > Of course ALL markup meanings at the intermediate stage can be used to
> > affect the final presentation. But their meanings should not be about
> > presentation or layout, So, role="MSc" is OK but align="right" is not.
> > The skin stylist should decide left or right and in any case the target
> > media might not have a left or a right. e.g. Audio.
> Agreed, and XHTML does not allow align="right" whilst it does allow 
> class="MSc"..
> >>
> >>"its main structures correspond to the general notion of what 
> >>constitutes a book"
> > 
> > 
> > Ah, excellent point! Note that "book" has two meanings:
> > 
> > 1) The media type called book. I.E. a blank hard back with a binding and
> > blank white pages.
> > 
> > 2) The content type called book. I.E. a novel or work of reference that
> > may or may not be delivered via the media type called book.
> Yes, but my point is that not everything can be represented as a book. A 
> book is, usually, linear. This section comes after that section. Not all 
> materials are, my trainning materials for example. Read my comment that 
> followed the above.

Its the media called book that is linear. Content called book is linear
if it is a novel, but not if it is reference material. But, yes I agree
that not everything can be represented as a book - that is why cruelly
suggested alternative intermediate DTDs. Penny still dropping...

> >>- I use forrest for training materials. Docbook *could* be used as a 
> >>source format but it is not ideal in my domain. I use other formats as 
> >>my source that have been designed for the purpose. By converting to 
> >>docbook as an intermediate format I will be losing semantic information, 
> >>which is something you say I shouldn't do, but something I am now 
> >>comfortable with (see above).
> > 
> > 
> > When an author writes a document or book using a DTD that is truely
> > media independent - he will have no control of style, layout or
> > presentation and should not think of such things. His document might be
> > delivered through any of many different style sheets for each of many
> > different media types. So, for the author, the cost of delivering
> > content to many media types is that he can no longer use style as part
> > of his message.
> What you say is true, but what you say is "When an author writes a 
> document or book using a DTD that is truely media independent".
> We are not talking about writing the document or book in XHTML, we are 
> talking about writing in the most suitable DTD and converting to XHTML 
> as an intermediate format for Forrest. Forrest then gives us the style 
> information without having to worry about it.

When I said write a document or book, I did mean anything. But I take
your point - the penny is dropping.

> I will not write my training materials in XHTMl or Docbook. I will write 
> them in a specially defined DTD, at that point I am not, as you say, 
> concerned with presentation. I'm not looking for an intermediate format 
> that gives me semantic meaning because...
> >>My point is, *no* (usable) intermediate format will be so expressive 
> >>that it can accomodate all users.
> > 
> > 
> > Quite. Equally true for whatever intermediate DTD you choose.
> Intermediate is what I said, read again ;-)

I think you are assuming single Intermediate format. I'm mischievously
still considering alternative ones ;-)

> >>On the XHTML side of things, the following text from the XHTML working 
> >>draft convinces me that XHTML should be the intermediate format:
> >>
> >>"The XHTML family is designed with general user agent interoperability 
> >>in mind. Through a new user agent and document profiling mechanism, 
> >>servers, proxies, and user agents will be able to perform best effort 
> >>content transformation. Ultimately, it will be possible to develop 
> >>XHTML-conforming content that is usable by any XHTML-conforming user agent."
> > 
> > 
> > Yes, an excellent and interesting point. But, hasn't XML sort of
> > displaced this approach to some degree? Maybe it will catch up again?
> XHTML *is* an XML defined language. XML is nothing more than a way to 
> *define* markup languages. It itself is not a markup language. Therefore 
> XML has *enabled* this approach rather than displaced it - or am I 
> missing your point?
> > XML is designed for XML > FO > PDF for instance. But if you try to do
> > XML > XHTML > FO > PDF you screw it all up.
> OK, this is very important. Why will it get screwed up?

Because my existing DocBook content will not render using my existing
DocBook style sheets - that are very rich and choose to use the meaning
of docbook markup to determine presentation.

> All we are proposing is moving from our existing proprietary docbook DTD 
> to a subset of the much more widely available, used and accepted XHTML.
> Currently XML > XDOC > PDF works just fine, what will change if we go to 

Now that penny that I think has dropped!

I think you are saying that the Forrest XHTML intermediate stage
represents a media independent presention layer. So, in the case of
something written in DocBook - it is transformed into XHTML - as was
understood. Although something written in DocBook (or other source)
should be free of presentational information, the transformation to
XHTML necessarily makes decisions about presentation. In other words,
the transformation aims to add presentational information, but in a
media independent way. Have I got it?

I'll assume I'm now understanding the XHTML strategy better. I think
you've made it clear that Forrest XHTML is not he same as XHTML. But why
not? Is it because XHTML is not what it sets out to be? Is it because of
the clumsy implications of css? To what degree is it possible to have
media independent presentational instructions? Perhaps just for a subset
of devices? I have reservations, I don't know.

So, I can now see that Forrest must pursue its FXHTML ambition (F as in
Forrest I hastily add ;-). And I must discard my DocBook style sheets
and instead write DocBook > FXHTML transformations.

OK I understand - I'll think about it. Thanks for your patience.

> Ross

View raw message