[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Client-side XSLT. Re: Bad News on IE6 XML Support
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@p...] Sent: 10 September 2001 03:38 To: David Carlisle Cc: mail@j...; xml-dev@l... 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>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|