[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: Paul Tchistopolskii <email@example.com>
- To: Paul Spencer <firstname.lastname@example.org>, email@example.com
- Date: Mon, 10 Sep 2001 20:53:34 -0700
> 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
> This will come, and there are XForms processors of a sort
> around now, but it's not there yet.
> 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
> 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 ).