RE: [xml-dev] RE: James Clark: XML versus the Web

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

RE:
------------------------
--> Kurt
> These are big areas. They'll require that people check in preconceived
notions at the door, and they will require champions that will be willing to
both put in the effort to be the reference implementers and to defend the
specifications from being co-opted by a given vendor.
--> Peter
I have nothing useful to add, but I would like to state that this
thread contains some of the most clear minded thinking about XML and
the future that I have seen come out of this mailing list in a long
time. Kudos to all who have contributed, I really, really hope that
someone can move this forward!
----------------------------


I too have enjoyed this discussion but I come at it from what I think is a
more pragmatic view.  Perhaps I'm too short-sighted, but I see the evolution
of standards have changed a bit since "the early days" ... At least in the
markup world.

XML has become *widely adopted*.  We may sit back at our keyboards and
complain about how this or that problem is bad and how we should rewrite the
whole thing from scratch etc.  But I don't see that happening easily.   Nor
do I see it as necessarily good.
I think XML and the "whole shark" (or as my IC design prof used to say "The
Whole  Enchilada") is an amazingly good thing.  Maybe I have just drunk too
much Kool-Aid but I don't see anything fundamentally wrong with XML and the
shark.  Sure there could be improvements.   
And sure there's a huge boatload of infrastructure and standards bolted on
that in the whole is a really big (and often ugly) thing.
But that doesn't make the core of XML "bad".   And it's a huge amount of
work to get the world to *change* now.

JSON was invented, not as a "Standard" but as a practical solution to one
problem, IMHO,  parsing XML in the browser wasn't universally supported.
But calling "eval()" was.  So why not just send JavaScript (in sheep's
clothing as "JSON") directly ? 
It's a pragmatic solution.      The *real* solution would have been to
strong-arm the Browser Implementers into doing things 'our way' and build in
XML parsing directly into JavaScript as a required functionality.     But
there you go, sitting back at the keyboard wishing everyone else would  be
required to do something  to benefit you.    Instead 'they' did what
actually was pragmatic, feed an encoding that worked without requiring
anyone else to change.
And it wasn't done as a "Standard".   It was just done by individuals, and
people who recognized it solved a problem copied it.


But what about XML ?  I still think XML is a superior technology to JSON ...
and I don't think it needs to be fundamentally rewritten or married with
JSON.
It may not have become "SGML on the Web" like the original intent, but it
*has* become a vastly adopted data model and unifier and enabler in both
vertical and horizontal markets.   in "Just 10 years"  (well a little more)
almost every major data technology is built on or at least supports as a
near-first class citizen XML.   That's *awesome*.    I call that an
incredible *success* and personally don't look forward to changing that.

But ok what about pushing XML into places it hasn't been adopted.   That's
really the discussion here, IMHO.  "We want to see XML in places it has
failed to be adopted".       Well JSON has succeeded in the browser (and now
in Web enabled devices) because of the JavaScript thing.
That's not going to change one iota by trying to mangle XML into a JSON
hybrid or rewriting XML.
Nothing is going to change that without enabling efficient XML parsers in
JavaScript (either built in or a library).
And does it *need* to change ?  JSON actually works in this environment.
It's not a "threat" to XML.    

The "Threat" as I see it, is the pushback from the places where JSON
actually works back up the enterprise food chain into places it really isn't
a good solution.   Ultimately, I predict this will just reanimate all the
problems XML actually solves well and get re-invented in JSON,  OR just
utter failure.

I don't think we need a parallel JSON Toolset ecology.    It can be invented
but it's a waste of effort, IMHO.
What we need is good *clean* ways of crossing the bridge, both ways, between
JSON and XML.
This hasn't been done to my knowledge.   There have been many attempts but
the reality is that its hard, or nearly impossible, to drive the XML Train
over the footbridge of JSON without losing a lot.  I'm working on one idea
currently.  We shall see if it actually works out ...
But most people have stopped trying, or have half-attempts and called it a
'non-starter.' because the problem can't actually be solved elegantly.

I'm not so sure that's a deal-breaker.   Is it so bad that the Train cant
cross the Footbridge ?

What's JSON good at ? Its good on *web enabled clients* (browsers & mobile
devices).   I work a lot in the mobile space, and I can tell you that what's
needed , at least with today's technology, in the mobile environment IS
stripped down data pre-formatted to as nearly as possible the exact
representation the app wants for a particular purpose.    Lugging the whole
Train (or "Shark") of XML to the browser and mobile devices is an instant
#fail ...   What *works well* is XML on servers running extremely expensive
transformations to tailor the content to exactly what *a particular client,
device, and person* want in exactly the form that's most efficient for them
and sending them that ... 

Which could be JSON ... (and often is) 
But it could also be XML ... a *customized stripped down XML*  that is
exactly what the client wants right this instant.
And for the most part, at least with today's apps and devices , the client
doesn't *need* 99% of "The Whole Enchilada".

It needs either a very concise stripped down data model for structured data,
and/or HTML for presentation data.
So what is the "Stripped down data model"  ?  JSON actually works well for
this.

So one solution is to *encourage* good quality JSON<-> XML transformations
... this relates to the next issue ... 

But it could be XML just as easily if there were XML parsers optimized for
this "stripped down model".
If they didn't need to support 'the whole enchilada' maybe they can be
written in a JS library compact and quick.

What I'm getting at is that if we actually want to send XML to devices &
browsers, they don't need the whole thing.
That doesn't mean we need to fundamentally change XML as a whole just for
this use case.
It does imply maybe there can be *subsets* of XML which are designed for
efficient uses in particular use cases.   This could be done without
changing XML at all.

A problem comes with "Which Subset"?   I suspect there will never be a
consensus, nor need there be.  Different apps and devices likely need
different subsets.   

Instead ... 
I'm imagining something like  Bluetooth "Profiles" or "XProc Processor
Profiles".
A well-defined set of subsets of XML, and possibly serialization formats,
designed for efficient use *in browsers and mobile devices*.
(or elsewhere,  but I specifically mention browsers & mobile devices because
most other efforts at "Efficient XML" don't target this space,
try decoding binary XML in JavaScript).

This doesn't even need to be a full-blown "Standard".   Look how well JSON
succeeded without a "Standard".
I suspect (actually have evidence of) people doing this all over, they just
are embarrassed to admit it.
Because if you only implement a subset of XML and you tell anyone you get
"Oh that's not XML !!!!" and instead of it being an enabling feature,
its considered a half-hearted incomplete hack not worthy of consideration
and your reputation is ruined for life ( 1/2 :) )

We can start this change *today* without throwing out XML, without
redesigning it from scratch, without abandoning it.  But with a simple
mental world-view change.   That its "OK" to use a subset of XML.   Its
actually *great* to identify the pieces a class of applications actually
needs and not bother supporting the rest.   This is a *feature* not a *sin*.
We don't need to jump on a whole new bandwagon to just realize that because
we have a Swiss army knife with sharks with fricken lasers attached, that
just using the screwdriver part is just fine.



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









 










_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php