Cart
|
[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. Let us see. > 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. OK. So you describe 'something' in XML. > 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? ??? So you send the XML document to the client and then client makes a *validation* ? You're saying that client-side XSLT may help you to *validate* something??? OMG. XSLT is *not* for validation! It is a language for blind transformations. Because XSLT lacks DTDs (not to talk about Schemas) I think it is obvious that using XSLT for validation of anything is very much outside of the problem domain of XSLT. > 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. Good! HTML is good! > 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 XSLT will not help you here. Really. > 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. I'm not questioning that delegating some processing to the client is a good thing! Java RMI (killed by MS) was providing a reach framework for distributed computing, including distributed validation. Of course distributed computing is good! I just don't get how can XSLT help you with this. XSLT is not for distributed computing and it is not for validation. Validation is a complex process. Good client / server balanced validation requires utilisation of system-level APIs which XSLT is lacking ( because XSLT is just a part of XSL ). Rgds.Paul. 
|
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
|
|||||||||
