Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@c... 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@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
