Re: Formatting Objects considered harmful

Guy Murphy wrote:
> Firstly youo are advocating that H1 is a desirable formatting semantic in
> your example.... or do I misunderstand you? You document does seem to be
> advocating HTML for format.
You misunderstand. But that could be unclear writing from my side,
let's go on...
> You further this by stating...
>
> <quote>
> The difference between example 1 and example 2 is one of semantics vs.
> presentation. When transformed into HTML, the semantics of the XML is
> preserved since the H1 element is globally recognized as being a headline
> of level 1.
> When transformed into XFO, semantics is removed and replaced by
> presentational properties.
> </quote>
>
> Suggesting that it is desirable to preserve data emantic into the
> formatting.... why? If you want to see the data semantic go look at the
> data.
In example 1, the H1 element preserves the semantics -- and says
nothing about formatting.
> And again for example 3 you state...
>
> <quote>
> The result contains both semantics and presentation. This is a good thing.
> </quote>
>
> Again... why?
>
> I'm sorry but you definately seem to suggest that the HTML tag has
> something to offer the formatting.... what?
Ahh, I think I see the reason for the confusion. Here's the XTHML tag
we're discussing:
<H1 STYLE="font-size:1.3em; margin-top:1.5em; margin-bottom:0.4em">
The headline
</H1>
In my mind, the STYLE attribute isn't part of XHTML since it's defined
in another specification (namely CSS). That's why I go on to say:
(When authoring with CSS, one would normally move the stylistic
properties into a separate style sheet. This eases maintenance and
makes documents smaller. However, both forms are valid and one can
programatically convert between the two.)
I will update the paper to make this more clear.
> The rest of your document seems based on the tenuous assumption that people
> will abuse XFOs and opt for them over eithere HTML+CSS or XML+CSS
Yes, I think there is a serious risk of abuse.
> Why would people do such a thing? What advantages does hand coded XFO have
> over HTML+CSS or XML+CSS.
I don't think it will be hand-coded. It will be machine-generated from
destillers and WYSIWYG tools.
> I'm sorry, but I don't believe your problem domain is significant enought
> to declare XSL Formatting Objects dangerous.
I respect your opinion, but disagree.
> In turn I would suggest that producing HTML from XML is dangerous as it
> forces a semantic upon the formatting that may well not be relevent.
>
> And you're suggestion that XFO are a danger to device independence over
> HTML!!!
Yes.
> As a side note.... As has already been discussed on this list, the model
> being drawn up for XSL output is potentialy a very strong one for multiple
> media formats, as there is no reason why FOs can't address visual
> formatting, and introduce new namespaces for new media....
>
> <aural:speech>Hello World</aural:speech>
The second FAQ discusses this:
Ok, but even if transformations take place on the server,
accessibility can still be preserved. By defining formatting objects
for all media types, presentations for all sorts of devices can be
generated, no?
In theory, yes. In practice, no. For example, to successfully present
content aurally, there are four prerequisites:
- there must be a specification for aural formatting objects
- there must be implementations of aural formatting objects
- the fact that the user has an aural client must be known to the
server
- all web sites must install XTL sheets to transform content into
aural formatting objects
Among these, the first two will require much time and work. The third
is undesirable, while the fourth is impossible in practice. Besides,
caching suffers.
> <quote>
> A Web of XFO documents can be compared to a Web of HTML documents with only
> FONT and BR tags.
> </quote>
>
> Small point, but I think worth noting that FONT and BR tags do not produce
> tree formatting.... I think comparing XFO to DIVs and SPANs would have
> addressed the issue better.
Or, better, DIV and FONT.
> <quote>
> Unfortunately, when transforming documents into XFO, all semantics is
> removed and only the human presentation is left. Moreover, the presentation is
> tied to a certain output media (which most likely is visual).
> </quote>
>
> No reason for XFOs to be tied to any one media.
No? Are you saying that a formatting object can be both visual and
aural at the same time?
> Yes the data semantics are removed, and replaced with formatting semantics
> for rendering. This does not suggest no semantics, simply semantics
> appropriate to the domain.
Here's our vocabulary:
Guy Hakon
data semantics semantics
formatting semantics presentation
I argue that there is a ladder of abstraction where what I call
"semantics" is above "presentation". On this ladder, it's easy to move
downwards, but hard to climb upwards.
> If you want to see the data semantics, go look
> at the data.
You make it sound so easy. This is the core argument I'm making: when
you receive an XFO document the "data semantics" is gone and there is
no way to get it back.
-h&kon
Håkon Wium Lie http://www.operasoftware.com/people/howcome
howcome@xxxxxxxxxxxxxxxxx simply a better browser
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list