Andrew> fantasy land when they conceived the xml-stylesheet PI and
Andrew> its media type attribute - it was a bit naïve to expect
Andrew> any mobile device to look for the PI with a 'handheld'
Andrew> media type, perform the transformation itself, and then
Andrew> get this univeral 'handheld' markup back that looks great
Andrew> on all mobile devices....
Why is this naive? If a handheld device is going to the
trouble of looking up an xml-stylesheet PI and performing the
transformation, then it's trivial (compared with the step of
performing the
transformation) to select the right one.
It's naïve because it's grouping all mobile devices under the one handheld
banner - if you can only specify one stylesheet for all handheld devices in the
world then the markup it generates will have to be pretty generic. It's just
not feasible.
Andrew> The whole idea of associating a stylesheet with an XML
Andrew> document by hard-coding it into the XML is wrong
It certainly isn't wrong - it's an excellent idea, enabling
clients to offload work from busy servers
It certainly is wrong - it's an awful idea. Offloading work from the server to
the client is a good idea (but still debatable), but achieving that through
embedding links to the stylesheet in the XML is just wrong - it ties that XML
to that stylesheet forever more. It's hardly been a success story has it?
What's needed is a far more flexible approach.
Andrew> it's a practice best avoided.
This is harder to argue against, given the lamentable state
of existing implementations.
Blame the spec, not the implementations, it was a bad idea from start (it is
possible that JC couldn't see into the future and misjudged some things).
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--