Subject: Re: Transformation + FOs makes abuse easy From: "Jonathan Borden" <jborden@xxxxxxxxxxxx> Date: Wed, 28 Apr 1999 17:28:48 -0400 |
Simon St.Laurent wrote: >At 02:08 PM 4/28/99 -0400, Jonathan Borden wrote: >> So you agree that, logically, the most open and semantically rich way to >>transmit information is via XML with conversion on the client into a >>presentation format. Whether the XSL sheet converts into XHTML+CSS or XFO on >>the client is irrelevent to the fact that the data started out as >>semantically rich, and perhaps arbitrary XML/RDF. > >Actually, no. I'd send XML+CSS and skip the XSL work, unless I had a case >which actually required transformation. (Converting a table of data into >an SVG graphic would be a good case for that.) There's no need to go to >HTML except to support legacy browsers. > Are we living in static document viewing land? Perhaps this is true. Are we talking about Web native application land (e-commerce, telemedicine, DAV etc etc) then I would love to see something really simple done in XML+CSS alone .... and I'm not counting the 'backdoor' XHTML as XML in this case. For example, create a form, edit some data, create a dynamic user interface, order a book, post a medical consultation, edit a document etc etc etc. The current choices are either: generate HTML on the server, e.g. ASP, CGI etc. or generate HTML on the client e.g. XSL. The browser using HTML+CSS is the VT100 of the 90's. Add XML and XSL and you have the VB of the 00's. If you factor this discussion into the 3 traditional computing tiers, the client tier builds the 'screens' that are used to interact with the user, process key strokes, etc., a network protocol is used to transmit data between client and server, on the server, the middleware tier processes the business logic and interacts with the database tier. Transmitting XFO or HTML from server to client is really nothing different than using a terminal server to keep or move the client tier back onto the server. Either way, all the client does is sit there and create screens from either XFO or HTML. This is not always a great use of server CPU cycles. This is useful only when client cpu cycles are much more expensive than client bandwidth, and even with handheld devices, fast embedded processors are lots cheaper than wireless bandwidth. Using the SVG graphic example, I think that having the server generate SVG for the client makes exactly the same amount of sense as having the server generate XFO for the client (and only slightly less sense than having the server generate HTML for the client). So, sure if XML+CSS does it for your task, then by all means go for it. But for that class of tasks for which CSS doesn't hack it, XSL ought fit the bill. Jonathan Borden http://jabr.ne.mediaone.net XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Transformation + FOs makes abus, Håkon Wium Lie | Thread | Re: Transformation + FOs makes abus, Chuck White |
How do you this XML document to thi, Francois_Deza | Date | Re: XSL is difficult to...?, Duane Nickull |
Month |