Re: [xsl] xml-stylesheet p.i. and other options (was Re: text/xsl...)

Subject: Re: [xsl] xml-stylesheet p.i. and other options (was Re: text/xsl...)
From: Mike Brown <mike@xxxxxxxx>
Date: Sun, 23 Jun 2002 19:51:01 -0600 (MDT)
David Carlisle wrote:
> XML is a _document_ format without implicit presentation semantics (so
> unlike HTML for example) as such you need to need a link between the
> document and some presentation rules.

But in practice, an XSLT stylesheet ends up being more than just presentation
rules, it is a complete reinterpretation of the data, often requiring
different interpretations for different audiences / clients.

If I've got some data I need to format five different ways depending on who's
looking at it, with the p.i. I have no way of making the decision of who gets
what variation. It's all or nothing, or I've got to force my application on
the server side to pre-write the XML with the right p.i. once it's known who
the target audience is. That's no way to go about things, but that's what I
have to do if I am bound and determined to use xml-stylesheet. Why should the
data document be saying "this is how you process me (if you care)"? Don't you
see how that undermines the whole notion of isolating the data?

If all you are ever doing is one kind of transformation for one class of web
browsers, then sure, you can use the p.i. ... but even then, you really didn't
buy anything by separating your data into the separate document. You might as
well have done the dirty work on the server side. The only freedom you've
offered the client is to either make use of the associated stylesheet or not.
That's another thing about the p.i. -- an application is free to ignore it.
Under what circumstances is that *ever* okay, in a real world application?

> One may argue whether a PI with "pseudo atributes" was the best possible
> syntax choice but that's a minor point. The fact of having a
> vendor-neutral link from the document is the important point.

It's not so much the syntax choice as its lack of usefulness outside of
a very specific set of circumstances, such as when there's no harm in the data
specifying where to find its processing rules since you might not ever need to 
make that decision elsewhere; and such as when you don't expect to ever be 
loading up that XML in an application that won't do what you're expecting it 
to do with that stylesheet association.

To be more useful it needs to have more options, like being able to pass
stylesheet parameters. And targeting different classes of applications would
be a good start. I suppose there's nothing stopping one from using different
processing instructions for different target apps, but still, I just don't see
why it's a good idea to embed pointers to application business logic in the
middle of an inert data document.

> Without such a thing then one can not hope to serve XML files over the
> web

But that's what people do every day, probably in far greater numbers with
server-side solutions than with the xml-stylesheet p.i.

> and XML was _designed_ to be SGML-light for exactly this purpose.

I can appreciate righting the wrongs that were made with the first SGML-light,
HTML, but it seems to me that one of the things they got right -- using <LINK>
to reference a CSS stylesheet, when CSS tends to amount to fine-tuning of a 
predetermined rendering algorithm -- does not scale well in XML when 
you start using <?xml-stylesheet?> to reference complex XSLT applications that 
may very well need to be part of a decision process of larger scope than just 
what can be accomplished within the XSLT itself.

I'm also failing to see why XML is needed as the basis of all things Web, when
the majority of web sites don't even have enough content to be worth isolating
and organizing the data for.

   - Mike
  mike j. brown                   |  xml/xslt:
  denver/boulder, colorado, usa   |  resume:

 XSL-List info and archive:

Current Thread