Re: Transformation + FOs makes abuse easy

["Jonathan Borden" <jborden@xxxxxxxxxxxx>]

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