RE: Client-side XSLT. Re: Bad News on IE6 XML Support

[Paul Spencer <paul.spencer@alphaxml.com>]

I agree that HTML was, and  is, a very good idea. But here is a usecase
where sending semantically rich data down the wire is better. We are working
on a project to move several hundred forms online, or, more precisely, to
make them available over a variety of media. Naturally, our first port of
call was XForms, unfortunately still in draft, but still the best option.

We can describe a complete user conversation in a single form coded as an
XML document. This can use multiple web pages, complex WAP interactions or
whatever other output media we like, but we are talking HTML here, so let's
restrict ourselves to that.

Wouldn't it be great to be able to send the single XML document down the
wire to an XForms processor on the client and get the validated instance
document back? This will come, and there are XForms processors of a sort
around now, but it's not there yet.

OK then, we will send the form down with some XSLT and JavaScript. In
principle, the user could now complete the form offline and reconnect to
send it. After all, the complete description of the form, including display
that is conditional on the content of the produced instance, has been
displayed in a single XML document. We could do this with IE6, or IE5 for
those who have updated to MSXML3+. Possibly Mozilla-based products as well,
but we haven't looked at that yet. But that will be a minority. So for the
moment, we are sending HTML down the wire.

Why is this a disadvantage? We now round-trip to the server for every new
page and have to hold our instance data across pages. We can't validate on
the client, so this is done on the server. And we still have to tailor
JavaScript for the conditional display. The system is slower for the user,
and harder for us. Browser compatibility is a problem, which XML promises to
eliminate by having implementations that are more standards-based. OK, we
haven't seen it yet, but I am going for the "hope over experience" approach.

There are plenty of other usecases, but most come down to offloading
processing to the client (where it's free) and saving server round-trips,
thus improving performance.

Paul Spencer
CTO, alphaXML Ltd
alphaXML is recruiting XML Consultants and Developers
+44 (0)1491 630053
http://www.alphaxml.com


-----Original Message-----
From: Paul Tchistopolskii [mailto:pault12@pacbell.net]
Sent: 10 September 2001 03:38
To: David Carlisle
Cc: mail@jenitennison.com; xml-dev@lists.xml.org
Subject: Re: Client-side XSLT. Re: Bad News on IE6 XML Support



> Client side transformations allows you to send semantically rich
> accessable data which is transformed as late as possible to the
> rendering-only form. Server side transformation means you have to send
> low level junk down the wire.

So you call HTML a 'low level junk' ? Or maybe you call SVG 'low level junk'
?
OK, I don't understand why sending "low level junk down the wire" is bad.

Could you educate me, please. *Why* this 'late possible transform'
*is*better*, than 'sending low-level junk down the wire' ?

Why sending, for example, HTML 'low-level junk' down the wire was/is
*bad* idea? I think HTML was *very*good* idea.

I have more things to say, but I'd love to see some particular usecase.
If possible.

Rgds.Paul.




-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>