Re: [docbook] Whatever happened too CSS+XML?

["Scott L. Holmes" <scottlholmes@yahoo.com>]

--- "Steven T. Hatton"
<hattons@globalsymmetry.com> wrote:
> I'm in favor of redefining best practices in
> terms of XML, not XHTML.

I apologize but my conscience prevents me from
failing to point out that the X in XHTML is the
same X as in XML. XHTML is XML.

> One of 
> the problems with using xhtml is the fact that
> it requires a significant 
> restructuring of the original (DocBook)
> document, and thus requires the 
> author and/or page designer to understand the
> mapping between these two 
> disparate forms.  

I'm not sure if I agree. I've produced some
pretty nice looking renderings of docbook to PDF
and I don't know a thing about FO - aside from
the fact that I'm pretty sure it isn't even
remotely related to docbook.

> Modern browsers and XML
> should be able to leverage the 
> native structure of DocBook and provide a full
> featured on-line interface.

I would state that a user that claims docbook
conformance _must_ correctly render what is
documented in the TDG. 

IE, Gecko, Opera etc are in no way obliged to
render docbook because they do not claim to
conform (any more than they are obliged to
correctly render say OWL or ANT.)

> This may require some rethinking of current
> approaches, learning new 
> technology, and pushing the browser technology
> to conform to the existing W3C 
> specs.  It will likely also involve modifying
> these 
> specifications/recommendations.

The mainstream user agents all correctly render
XHTML with very few defects. Most also correctly
render many day-to-day XML/XSL chores. When I say
correct, I mean they render this content in an
accessible fashion that complies with the
recommendations of the W3C.

The user agents are not the problem. No one in
this thread is recommending that Adobe change
their specs or update their PDF render so that it
directly renders Docbook.

I reject the idea that XHTML rendering user
agents need to render docbook directly.

Docbook is an excellent vocabulary for sourcing
other documents. Let's work from there. I'm
pretty sure we already have enough technology
developed to do everything we want. We don't need
more.

>  The pace where
> XSLT would play a role is in 
> generating XML indexes, links between the
> indexes and indexed terms, links to 
> and from glossed terms and glossary entries,
> TOCs, etc.  

And here is where I'm lost. Because there is
almost no precedent for your list on the web,
I've found it extremely difficult to find well
defined best practices for exactly what these
items are supposed to look like using XHTML (both
semantically and presentation-ally).

XHTML and XSLT isn't much help when you almost
never see and index or glossary. I'm working on
it though. Docbook has it easy somewhat because
most folks are expecting a nice flat two
dimensional document stream and not a
multi-dimensional hyperlinked web site.

> I understand why people use XSTL transforms
> into XHTML. I do it.  But I 
> believe there is vast potential in breaking out
> of the XHTML framework.

I believe there is much uncharted territory yet
to explore. Just a couple of searches on Dublin
Core or CSS Image Map will keep you busy for
weeks.

> I've build modestly sophisticated web pages
> with nothing but CSS and XML.  I 
> know it can be done, and I know there are some
> problems.  One thing some 
> people on this mailing list seem to be missing
> is that they are (or can be) 
> the driving force that determines which way the
> technology goes.  

This is why I'm commenting. I surely can't be the
only one that sees things the way I do. I'm
fourty something, I like long walks on the beach
and quiet moments in front of the telie.

> The 
> response that the browsers don't support it, so
> it can't be done isn't a 
> valid argument.

Steve. We're on two different roads leading to
the same definition.

Cheers!

Scott