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

[Paul Tchistopolskii <pault12@pacbell.net>]

> 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.