Claudio,
The magic combination of standards-adherence with wide accessibility (i.e.
reach some high percentage of browsers) is still difficult to achieve with
generic XML, perhaps even impossible on the client. (I leave aside the
growing number of XML applications, such as RSS or SVG, that do an end run
around this problem for their particular application.) This is because
although 80-90% of what is necessary is standardized -- XML and XSLT -- the
last 10-20% is *not*, and may remain so. :-( That's the part that
configures the browser when the document is loaded, loading the appropriate
stylesheet (perhaps letting the user select it), passing parameters in, and
the rest, and provides the end user with whatever interface they need to
configure and run things further. The sort of standard xml-stylesheet PI
(the thing that goes "<?xml-stylesheet type='xsl'
href='mystylesheet.xsl'?>") goes only part of the way there -- beyond a
simple one-to-one relation between documents and stylesheets, with no
parameters and no user-driven styling, we have to resort to proprietary
interfaces such as the MS VB/Javascript stuff (which of course only runs in
IE).
So we route around the problem, processing the XML on the server to give
browsers what they are used to: HTML. This processing can be either
on-demand ("dynamic") or ahead of time ("batch mode"). HTML/CSS/scripting
is powerful enough so that most anything can be achieved this way,
dynamically over http when necessary (though scaling the system is harder
than it would be in the client-side model) -- but it does mean that you
can't serve up plain files, but have to run some kind of process on the
back end. In turn, this means either access to a server (running Apache
Cocoon, or something analogous such as the 4Suite engine in Python that
I've been trying lately), or constraining yourself to the batch-processing
model David and I have described.
It's true that we lose many of the promised strengths of XML by doing this:
there's a great deal that's attractive about being able to process on the
client. But without a "killer app" (a breakthrough application that
demonstrates the strength of the paradigm and brings all competitors with
it), there appears to be no incentive for the browser vendors actually to
get together and develop a standard API for loading and configuring
client-side XSLT. (For whatever reason, they prefer the zero-sum battle of
proprietary interfaces to the positive-sum platform of a standard all can
work with.) Consequently, if you *must have* your XSLT processing happen on
the client, it's still very difficult (impossible) to stay browser-neutral.
XUL, anyone? (Where did that go? Can you drive XSLT processing through it?)
Cheers,
Wendell
At 09:06 AM 7/2/2003, Claudio wrote:
But this will tie me up with a specific technology instead of begin
adhering straight to standards and open tech. For sure this technology is
one step ahead of the standard but unless is a standard by itself (which I
doubt from the msgs coming to this list), will be difficult to see
applications running smoothly in, lets say, at least 90% of the clients
machines.
As I said, I've been playing a little bit (for sure not as much as you did
guys) with the XML/XSLT technology and is time to wrap up and take in
concern what I mention before, being able to deploy a site with minor
environment problems, inmediate adherance to standards and simple maintenance.
Claudio.
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list