Re: XSL and HTML

Subject: Re: XSL and HTML
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 14 Jan 1999 11:07:11 +0200
Paul Prescod <paul@xxxxxxxxxxx> wrote:

>Guy claims that if XML does not directly support HTML developers will "do
>their own thing" and that will hurt XSL and the W3C. The only problem with
>that theory is that "doing their own thing" is exactly what the W3C would
>recommend you do for server-side translations.

Ah, but I'm running my XSL->HTML/JavaScript conversion on the client side
:-)

>Comparisons to the frames issue is not relevant. Frames are distributed on
>the wire. ASP is not.


And I am sending XML over the wire to be converted to HTML inside the
recepient browser :-)

>On the wire, translating to HTML+JavaScript makes no sense.

Well, I'd love to see an alternative. Not only it reduces my bandwidth by a
large factor, it allows me to generate HTML tailored to the extact browser
version the client is using (without burdening the server with any extra CPU
load), _and_ there's built in support for this inside IE5. Oh, and it will
work _today_ inside any Java/JavaScript enabled browser.

Still makes no sense?

>Sure, we need
>interactivity, but generating Javascript code is not an intelligent way to
>do it. Since the W3C's mandate is to build a robust information system for
>the future, I expect that they will continue to keep their priorities
>clear.


Delightful. So until they come up with something better - and I'm not saying
they won't, just that it will take a year or two - until then, I'm expected
to twiddle my toes and not distribute interactive applications on the Web?

It isn't as if the technical issues in question require overhauling XSL,
corrupting it with numerous tags which will compromise it forever. What we
need is a very small number of tags, all of which are variants of
<xsl:text>, are trivial to implement, and would get all these anoyying
dHTML/JavaScript people of your back so you can work in peace on the right
solution.

For the record, I'm talking about <xsl:cdata>, <xsl:char-entity> (which
arguably fall under the current intent), <xsl:not-xml>, and
<xsl:ecmascript-string> (which don't). For all I care, name them
<xsl:x-not-xml> and <xsl:x-ecmascript-string> so that people will know they
are 'extra' tags and might be removed in the future, make it clear that if
you use them you can't verify that the output conforms to any DTD, and so
on.

What possible advantage there is in _not_ providing these tags is beyond me.

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread