RE: [xml-dev] ten years later, time to repeat it?

[Len Bullard <len.bullard@uai.com>]

Which is why Simon points out the need for organizational efforts over a
'roll our own' subset.  OTOH...

My problem with the subset idea is simply what this thread usually produces:
it's tough to get buy in on what to leave in or leave out.   IME, DTDs are
more likely to be understood by non-XML-Dev developers than XSD, yet it is
always top of the death list.  Everyone hates namespaces but no one has a
proposal to submit.  And so on...

I'm not saying there won't be consensus but I'm not sure I see one.  XML got
done because a self-selected group of experts did it without much overview
from the SGML user base with the exception of the Working Group members.
Even then, they/we were sort of a chorus, not a decision making body.  With
the exception of Dan Connolly, the W3C mostly ignored what was going on
there even if TimBL approved it.   It was a burglary in the sense that ISO
didn't have much choice about what was to be done to SGML and there
certainly were SGML vendors who were not pleased even though among the hard
core, there was a rough consensus that SGML On The Web was the opportunity
for a redesign effort.  Even then, it wasn't clean because the HTML legacy
and sense of accomplishment was given primacy.

That all washes out in the rosy backward glance, but only because SGML was a
niche metalanguage at the time.  XML isn't.  The price of winning is ruling
in the spotlight.  How many eggs do you want to break?

len

From: John Snelson [mailto:john.snelson@oracle.com] 
 
Joe Fawcett wrote:
>> That said, JSON seems to be contaminated with JavaScript cruft. For
>> example, instead of:
>>
>> "foo": 123
>>
>> you should be able to do:
>>
>> foo: 123
>>
> You can use that in JSON if you prefer, the quotes are only needed for
property names with spaces.

Not according to the grammar at json.org, or the JSON RFC. That's 
probably one of the big problems with JSON - there are lots of subsets 
of Javascript object notation that people think are valid JSON, but 
actually aren't.

John

[1] http://www.json.org/
[2] http://www.ietf.org/rfc/rfc4627.txt

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.