RE: [xml-dev] Where is XML going

["David Lee" <dlee@calldei.com>]

I'll stil bite and raise you a devils-avococate.
Explain to me why its "better" that XML be translated in the browser to presentation then on the server.
In either case someone has to author the translation buisiness logic (be it XSLT, CSS or whatever).
So what is the advantage to having this done in the browser vs the server (or whatever "smart filesystem" or "database" is "serving" the XML content).
Compare/contrast that to the cost of requiring ALL browsers in the entire world to adopt your technology vs only requiring the server hosting the particular content to adopt it.



----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

-----Original Message-----
From: Ben Trafford [mailto:ben@prodigal.ca] 
Sent: Saturday, December 04, 2010 4:15 PM
To: David Lee
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Where is XML going


On Sat, 2010-12-04 at 14:39 -0500, David Lee wrote: 
> But to the core of it, what is the "Mission Statement" ?
> There seems to be a *presumption* that where XML is 'failing' its
> because  it didn’t live up to "SGML for the Web".
> 
> So ok, we want XML "on the web" whatever that means …
> 
> But do we ?

Yes, we do. And here's why:

There are data and document models that cannot be represented in HTML.
Fifteen years of thinking of XML as a lower-level data representation
language have led everyone to the conclusion that "well, we can just
transform it into HTML (or PDF or whatever)."

There is no reason, in most cases, that transformations are necessary,
other than that there is no native browser support for XML that is worth
a tinker's dam.

There are, quite literally, -billions- of XML documents sitting in
corporate repositories that might happily find their way onto the Web if
browsers would support them with something as simple as a CSS
stylesheet.

There are several technologies which spring from web browsers (ebook
reading software being a notable example) that cannot handle native XML,
and would benefit from it. 

When we talk about XML on the Web, we're talking about going from this
process:

Develop schema -> Write XML document -> Test XML document with native
delivery mechanism and obscure tools -> Write transformation -> Test
transformation -> Deliver transformation to ubiquitous environment

to

Develop schema and stylesheet -> Write XML document -> Test documents
with well understood and supported tools -> Deliver to ubiquitous
environment

Doesn't seem like much of a difference, to a developer's eyes. To a
process geek like myself, I look at that and think, "Okay, so, I've cut
out $100k off my licensing budget for the obscure tools. I've cut 20%
off my development and delivery time. I don't need to hire for obscure
skill sets like XSLT just to leverage the power of XML."

And then I think "$$$$$$! WOOHOO!"

-That's- why we need an XML that is compatible with existing web
technologies. Not because it's some ivory tower dream of wonderful
unicorns dancing in rainbows, but because it will save people a lot of
money. 
--->Ben