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] Whatever happened too CSS+XML?

Okay: do we agree that transformations are often required for production
Web publishing?

Do we agree that CSS cannot do them, and therefore depends on
transformational technologies?

Do we agree that XSLT is a fine tool for doing these transformations
though there may be others?

If so, then it seems the crux of our debate is the question is whether
the output of these transformations should be XHTML or a normalized form
of DocBook with TOCs, Indexes, inlined cross references, etc. My
position is that generating either one is roughly the same amount of
programming effort -- the transformation is the hard part, not the
translation of element types (that's a trivial mapping exercise).

And applying CSS styles to either one is basically the same amount of
effort (are you applying to element types or classes). 

So there is no architectural simplification available.

So then your question becomes: "What would DocBook/DITA/TEI in the
browser gain you or lose you?" 

In today's world, I'd be curious about its affect on the following
aspects of web publishing:

	* search engine indexing
	* search engine link recognition	
	* browser recognition of links in general and semantically
meaningful ("role") links in particular
	* browser recognition of images
	* rendering performance
	* compatibility with screen readers
	* compatibility with mobile phones, set-top boxes and other
limited devices
	* compatibility with minority browsers like Safari, OmniWeb,
	* compatibility with link checkers
	* compatibility with web content management and web publishing
	* compatibility with advertising injectors

Let's say that all of that stuff is updated to work with XML+CSS
(millions of dollars of investment, but anyhow...). Are we actually in a
better world? Because HTML's element type names are globally meaningful,
platforms that typically lack a specialized stylesheet (e.g. a screen
reader, web scraper or mobile phone) can "figure out" the content. But
in a world of arbitrary element types floating around the Web, they will
find this problematic.

 Paul Prescod

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