[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: Formatting Objects considered harmful

Subject: RE: Formatting Objects considered harmful
From: "Jonathan Borden" <jborden@xxxxxxxxxxxx>
Date: Mon, 26 Apr 1999 23:03:25 -0400

Paul Prescod wrote:

> That is exactly Hakon's point. A well-constructed XHTML+CSS document
> contains abstract information that *cannot* be expressed in an XFO
> document without resorting to non-standard conventions and extensions. The
> reverse is *not true*.  There is no abstract information that a FO has
> that HTML does not suport. As Hakon said in the first message of the
> thread, from an accessibility point of view we need to move up the
> abstraction ladder, not down it.
	So you are saying that it is possible to create a transformation which
takes an arbitrary XFO -> XHTML and back i.e.

1) exists <t,t'>  for all (a) such that XFO(a) -t-> XHTML(a) -t'-> XFO(a)
but not an arbitrary XHTML -> XFO and back i.e.

2) not exists <u,u'> for all (b) such that XHTML(b) -u-> XFO(b) -u'->

	In this case, the essence of the argument is that XHTML+CSS is a better
formatting/UI language than XFO, that XHTML+CSS can do everything that XFO
can do and more. If so, from my position as a total formatting dummy, why
does XFO exist?

> I don't see why people are fighting so vehemently against a language that
> would have HTML-level abstractions and support XFO-level presentation but
> it seems to me to be the right solution.

	To be honest, I don't personally have a need for XFO, as XSLT allows
transformation of arbitrary XML into XHTML+CSS, which serves my needs
perfectly. It appears that some people feel that HTML+CSS is limiting for
things such as high-quality printing etc (things which I've not been
involved with and have no personal opinion on), and if this is true, XFO may
find a niche in these environments. My strong preference is to contain
semantics in XML documents (arbitrary XML documents) which are converted to
presentation via XSLT. In some cases one might even argue that DSSSL,
officially allowing Scheme 'extensions' is superior to an XSLT devoid of the
ability to officially call out to JavaScript, Java etc(as every
implementation I've seen allows).

	The *only* reason at least I have argued about this is the implication that
a)XHTML is equal to arbitrary XML for representation of semantic information
and hence b) there is no need to XSLT on the client.

	My summary of this long argument is that you are saying that XHTML is a
better presentation/UI language than XFO, one important reason being that
XHTML operates better in aural environments. This supports my inclination to
continue transmitting arbitrary XML to the client for XSLT into XHTML and
rendering by the browser.

Jonathan Borden

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread