W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2011

Re: Totally non-conformant JSON hack

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 10 Oct 2011 11:04:10 -0400
To: XProc Dev <xproc-dev@w3.org>
Message-ID: <m24nzgkhw5.fsf@nwalsh.com>
Zearin <zearin@gonk.net> writes:
> I have nothing against JSON. For certain things, it’s probably
> better choice than XML. What annoys me is, for other things, JSON’s
> popularity actually hurts XML’s progress! To developers who aren’t
> familiar with the more powerful tools of XML, JSON appears the
> superior choice. From this perspective there appears to be no
> obvious reason to ever look back to XML for anything.

In fairness, if JavaScript is your world, JSON is easier to use than
XML. I wish we'd been able to fix that by providing better XML APIs in
the browser, but that ship has sailed.

I think over time a balance will be achieved. The sorts of data folks
want to pass around will grow in complexity until XML is a better fit
for some of it, and if we make JSON easier to use with XML tools,
that'll help too.

>     The medium/long-term solution to this problem, I think, is to amend
>     the XML data model (as the XSLT WG is doing for the XSLT 3.0 (and the
>     XQuery WG *is not* doing for XQuery 3.0, sigh.))
> Wait—what?!  

Uh. Nevermind. Move along. Nothing to see here. (Apparently the
relevant drafts haven't been made public yet. I thought they were. My
bad. Stupid member-only working groups.) [Evidently ranting is going
around this morning -ed]

>     4. If a p:document element fails to load XML, XML Calabash tries to
>     parse the data as JSON and returns an XML representation of that if it
>     succeeds. (This is the worst part of the hack, but it's hard to tell
>     what the MIME type of a random file is.)
>     I have very mixed feelings about this sort of hack. As a standards
>     guy, it's clearly a violation of the spec and a source of
>     interoperability failures. As a user who's bloody frustrated by the
>     state of web APIs, it just quietly makes my life easier and better.
> Not crazy about this idea.
> Why can’t the processor just tell if it’s JSON from its extension?
> I’ve never seen a JSON document use any XML file extension.

I was going to enable this behavior only for .json files. But what about .js files.
And what if there's JSON in a .j file? Or a .txt file?

>     [*] I moved the <json> element and its children into the c: namespace.
>     Sorry if that trips you up. My bad.
> Does that mean it will be like this?
>     <c:namespace>
>     <c:json>

No. I mean when I first introduced support for application/json in
p:unescape-markup, I produced <json><pair name="...">...</pair></json>
documents, now I produce <c:json><c:pair name="...">...</></> documents.

Actually, by the time I release this functionality, I'll probably produce
JSONx documents.

                                        Be seeing you,

Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676

Received on Monday, 10 October 2011 15:04:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:09 UTC