Re: [xsl] xml-stylesheet p.i. and other options

[Mike Brown <mike at skew dot org>]

David Carlisle wrote:
> The point of XML was to be a lightweight form so that the source itself
> could be served over the web rather than doing it SGML style and doing
> the transformation at the production side.

I think we all tend to say on this list what the point of this or that was,
but we weren't at those meetings, and we all know that XML gets used for
all kinds of things, some reasonable and some absurd. The number of times we 
scold people for using d-o-e because they insist on treating markup as cdata 
in their input but not their output should be testament to that :)

I think the point was for it to be a vehicle for data interchange, upon which 
things like web applications can be built. Transforming and adding semantics 
is all much higher level stuff.

> Once you have a document, you might want to do other things with it. Not 
> least, print it. A Docbook+MathML+SVG (or XHTML+MathML+SVG)
> document is a lot more useful and content rich than an HTML file with a
> pile of gifs.

Of course it is, but if you've said in your Docbook XML that if I want to
style it, I've got to use stylesheet 'my-custom-docbook-to-html4.xsl' with it,
then that doesn't do me any good if I needed XSLFO, does it?

> > 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?
> 
> Any application is free to ignore anything, a PI is no different from an
> element. <script <style <object; none of these are guaranteed to have any
> effect.

My point exactly. So if you are pointing the masses to yourDoc.xml that
contains <?xml-stylesheet href="yourOneAndOnlyWayToTransformIt.xsl"  
type="text/xsl"?>, then you hopefully aren't expecting that yourDoc will
always be processed with that stylesheet. If you can live with the "maybe" and
if you can live with that being the only stylesheet that you'll ever need,
then there's no harm. But if your data is more general and its recipients more
varied in how they need to interpret it, then the PI is less and less
appealing. And more importantly, why should you have left it up to the client
anyway? I suppose it's nice to have the choice, but it seems like you hardly
ever, in the case of XSLT applications, want to risk having your XML to go
'unstyled'.

> > But that's what people do every day, probably in far greater numbers with
> > server-side solutions than with the xml-stylesheet p.i.
> 
> If they are server side solutions then aren't they shipping html rather
> than XML?

Why assume that? I've worked on applications that dealt with 6 kinds of XML
in, 2 kinds of XML (for different automated recipients) and 6 kinds of HTML
(for humans with web browsers) out. There were like 8 different stylesheets,
thus requiring some external logic to select which importing stylesheet to
invoke, based on who needed it and what the input was. Can't do that with 
xml-stylesheet, and the input XML wasn't even under my control, it was coming 
from elsewhere; I wasn't about to tell them to start hard-coding PIs so we 
could "maybe" offload some of the processing to some of the clients.

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/

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