[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 Spencer <firstname.lastname@example.org>
- To: Paul Tchistopolskii <email@example.com>, firstname.lastname@example.org
- Date: Tue, 11 Sep 2001 17:54:54 +0100
Let me just pick a couple of points to reply to:
> > 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.
Either I explained myself badly, or you are allowing your prejudices to
show. I am using XSLT to display and a validating parser to validate. The
fact that both are on the client means that my server is not interested
until it has a complete valid document to process.
> > 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.
> 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.
Absolutely XSLT helps. It is not essential - we could use the DOM. But it is
the combination of XML, XSLT and some simple script that allows us easily to
change the display of the form depending on the data input without round
tripping to the server. What saves the round-trips (and so improves the
performance) is not the XSLT per se, but the fact that it is being executed
on the client.
CTO, alphaXML Ltd
alphaXML is recruiting XML Consultants
+44 (0)1491 630053