RE: XML / XSL vs. [x]HTML / WML / etc. etc.

Date view Thread view Subject view Author view

From: Gavin Thomas Nicol (gtn@ebt.com)
Date: Mon Sep 18 2000 - 19:02:24 PDT


> At the core of this is the idea that users will visit the same site using
> their Web TV, thier Palm, thier Linux-powered wrist watch or the tactile
> response browser embedded in their bridge work.

Not the same users, different users. The key is reusability. I've
seen companies save $20,000,000 a year on this idea.

> I mean, it sounds plausible, but I have big questions on
> practicality and scalability.

Well, I've been doing it since 1994, and others (not necessarily
SGML-based markup language systems) have been doing it for a whole
lot longer.

> 1) Desktop vs. Palm vs. Phone (vs. watch vs. bridge work) ...
...
> will have only distant simularities between the different devices
> (or should I say "experiences"?).

Potentially, yes. This is somewhat data dependent obviously.

> 2) XSL transformation. O(n)? O(n ^ 2)? O(n!)?

Well, XSL *is* turing complete... so yes, there is potential
for misuse. The good news is that XSLT is *way* overkill for
many things, so typically things are closer to O(n) (where n
is the number of nodes travelled during the transform). The places
where you do find departures are typically in deep structural
transformations such as table conversion. Some common things
can have special-purpose indexes built to improve performance.

> 3) Memory usage.
...
> O(n)) ... but The People demand performance so not generating
> that XML in the first place is hard to resist.

Well, this is a greate fallacy waiting to be dispelled. You
don't *need* the whole document around all the time.

> 4) Got a use case?

I've got plenty. One is a bank I did work for... most of their
people use Palms for both content creation (via simple forms),
and information consumption. The same content is also used to
generate more sophisticated online reports.... which are augmented
with explanatory prose, links etc. The same data is also used to
produce a bound volume of credit reports.

These types of situations come up *everywhere*. Look at the DOM
spec for example, which is written is XML, but which produces HTML,
JAVA/JavaScript/CORBA bindings, and also PS and PDF.

> 5) Re-use. Is this the best approach for re-use? Isn't the
> whole argument based on the idea of doing *way* too much in
> the presentation layer?

No. It's really like OOP. In OOP, you want objects to capture
a little functionality beyond their core as possible (ie. restrict
the object to object data and methods). Adding baggage makes it
harder to use the object (can only be used in this type of
application). XML is *really* about explictly marking up the
inherent structure of textual data so that the data can become
information in different contexts. Data interchange etc. were
secondary drivers.

> J2EE and/or Jini provides all the mechanisms for good back ends,
> where the data comes from real objects and the presentation
> layer is a thin, but critical presentation layer.

Yep. Pretty much the old MVC model. In some cases, XML makes no
sense... in fact, it has been over-hyped, and misused in many
situations recently.. for example, using XML for protocols
makes sense in some cases, but not in all cases. Same for
data interchange... I often get EDI folk asking me if they
need XML... and I say "If your system is working fine today,
why change anything?". The point being that XML for messaging etc.
is great as a bridge technology (glue), but is not always
ideal as *the* way to do things.

> 6) Finesse. Users demand a certain level of finesse for thier
> applications... on the desktop, they all but demand involved
> interfaces super-charged with DHTML and JavaScript.

I understand your point... it makes maintenance much harder
than you'd like. Here, the most important thing is the data.
If the data is pretty generic (technical manuals etc.) you
don't need the bells and whistles, and the payoffs are much
higher.

That said, we could have done far better in
the WWW than the whole JavaScript/DHTML bogosity, but we're
stuck with it for now. Hopefully it won't take too long to
move away from it... but I can't really see it happening
for a number of years.


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Sep 18 2000 - 19:07:34 PDT