[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote:
> The "solution" is to transform on the server and send HTML down the
> wire. On the server of course you know what XSL engine is being used and
> you can get whatever HTML you want, but that means you're just sending
> presentation oriented HTML down the wire and in that case why was XML in
> the loop at all? Could just have well had SGML at the back and used
> DSSSL. XML was supposed to be SGML-light for serving over the web wasn't
> it?
I wasn't at those meetings, and anything I could add would be restating what
I've said before. It's a matter of opinion as to whether and to what degree
the exploitation of deliberate scope limitations or oversights in the specs
are impeding the success of XML and the web.
At any rate, aside from MSXML's DOM whitespace stripping and the lack of
serious competition for MSXML, there is at least one other reason why
client-side XSLT transformations are impractical on the Internet:
The typical data set / stylesheet combination is almost always larger than the
pre-rendered data -- in my experience, large enough to be impractical when
usability experts are demanding load times of 5 seconds over 56k modems. I've
seen at least two unrelated projects now that needed to combine 10-20K of XML
with some 500K of XSLT. Client-side DocBook, anyone? Granted, as high-speed
wireless rolls out, this will be less of an issue, but for now I see the
overhead of shipping a chunk of a database and rendering instructions down the
wire as being more of an obstacle than disappearing whitespace. Again, that's
just my opinion, though, informed by the projects I've worked on.
- Mike
____________________________________________________________________________
mike j. brown | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
|
