[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] XML Redux
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: stephengreenubl@gmail.com
- Date: Thu, 17 Feb 2011 12:02:39 -0500
I think this might be a good point to bring back discussion on E4X, which did in fact solve most of the issues that have been brought up on the list several times. It treated XML as a native data type, provided a JavaScript syntax for working with the XML native type (and XMLList type), could easily have been incorporated into JSON. It was supported by Mozilla and Flash, and would have gone into the next version of JavaScript if the decision hadn't been made to try to do the harmonization (which was basically a back-track that was driven primarily by Microsoft, as far as I could tell).
It was never clear to me why E4X wasn't a joint W3C/ECMA initiative, given that it deals with both specifications, and maybe it's something that, with all the discussions being made about XML and HTML, should be brought forward as a joint initiative now. By providing a formal, uniformly agreed upon base specification for E4X (or whatever it becomes) then most of the discussions about needing a simpler XML become moot.
I do not believe, and have not believed for a while, that the problem with XML is the syntax. There's a common profile of XML that most people use that use 80% of the features, and these work just fine, but you can expand out to the remaining 20% of features now if you need them. The problem is that the TOOLS for working with XML in the browsers suck. Long, complex DOM name calls, XPath requiring six objects to do anything useful, an eleven year old implementation of XSLT with incomplete support. Provide better tools in the browser, either E4X, XQuery in the Browser or some similar language, and people who hate XML for legitimate reasons (it's a pain in the butt to work with) will not have that argument.
Kurt
On Thu, Feb 17, 2011 at 11:24 AM, Stephen Green
<stephengreenubl@gmail.com> wrote:
So is there any need at all that the syntax be readable
at some point in the data flow/lifecycle by Javascript?
Doesn't interoperability with JSON imply readability by
Javascript, even if Javascript isn't always a target
consumer of producer? Or is there really no need at
all for interoperability with JSON or with Javascript?
If that is the case then what are the benefits of using
JSON syntax? Is it just a convenient, ready-made
syntax known widely and used widely? Is it just that
(re)using JSON syntax reduces the overall learning
curve for the many people who already know JSON
(much as Javascript and Java and other languages
borrowed from C)?
----
Stephen D Green
On 17 February 2011 16:02, Dave Pawson <
davep@dpawson.co.uk> wrote:
> Javascript constraints were never in my mind at all Stephen?
> Nor Jsons.
> My starting point was Liams blog and Mikes syntax?
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
