RE: Where is XML going
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 email@example.com http://www.xmlsh.org -----Original Message----- From: Ben Trafford [mailto:firstname.lastname@example.org] Sent: Saturday, December 04, 2010 4:15 PM To: David Lee Cc: email@example.com Subject: Re: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format