|
[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
RE: Percentage of web services supporting XML versus JSON
- From: William Velasquez <wvelasquez@visiontecnologica.com>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Tue, 10 Jun 2014 14:04:23 +0000
Does anybody know the format used in our brains to store information?
Is it JSON, XML, ASN.1 or any other?
It would be nice if we just can avoid data transformations and just transfer data from our brains to bits in a computer and the way back. Until
that, all markup languages will be based on (incomplete) abstractions.
That’s the reason the different markup languages should sit together to settle their differences.
We, the creators of systems and applications, are afraid that in the next 2 years a new “final” format appear and then we’ll have to rewrite all
our code to support it.
-
Bill
De: Uche Ogbuji [mailto:uche@ogbuji.net]
Enviado el: martes, 10 de junio de 2014 8:45 a. m.
Para: Steve Newcomb
CC: xml-dev@lists.xml.org
Asunto: Re: Percentage of web services supporting XML versus JSON
On Tue, Jun 10, 2014 at 6:50 AM, Steve Newcomb <srn@coolheads.com> wrote:
Loic says "a lot of data is maps" (in the sense of JSON objects, Python
dictionaries, etc.). While that's true, document are mainly lists,
because order is vital. Moreover, naming (the selection of map keys) is
implicitly the act of deciding what each thing is.
Historically, this discussion keeps spiraling through the same
neighborhoods. One perspective, let's call it "A", is focused on
communications technology. The other perspective ("B") is focused on
information interchange -- actual communications in all their glorious
chaos, imprecision, etc. "A" always thinks "B" would work better if
only everything were done in response to A's insight-du-jour (some jours
are very long days indeed, viz. ASN.1). "B" is unable to respond to
such rational argument, and is generally impatient with A's naivete.
After all, B is the suboptimal context in which the discussion must take
place -- a key point generally missed by A. (And when that point is
*not* missed by A, A tends to throw up its hands and apply an atrocious
hack, e.g. XML Namespaces.)
Personally I think it's better to focus on B. I have to force myself to
recognize that while B is my perspective, A's perspective is both good
and necessary to B.
<aol>Extremely well put.</aol>
Because of my perspective, I think:
* It's better to pay the cost of preserving ambiguity than to outlaw
ambiguity. Black markets bite back. Even more fundamentally, unclear
thinking is the only available path to clear thinking.
Amen a hundred times over. Ever since my engineering training days I always leaned towards the pragmatics/socio-economics pole of the profession rather than the specification-as-dogma pole. If it were possible I've become even more convinced
of this from my recent work in library information systems. Ambiguity is intrinsic of the natural world, and magnified a thousand times by human concerns. There is no way to compute it away.
* It's better to pay the cost of uttering names repetitiously in exactly
the way people use them. If that uses a bit more bandwidth, so be it.
Conserving bandwidth will not save the planet, but history demonstrates
that human confusion and ignorance can certainly lay the planet waste.
(Personally I find Loic's "save the planet" argument rather off-putting.)
* XML is terrible, but, like democracy, it's still the best available
choice because it is the most humane choice. Like XML, democracy could
work a lot better if it weren't so profoundly stiff in its operational
details. Will we ever have a more perfect union? Probably. Will we
ever have a perfect union? Probably not, but that's OK if the story can
continue.
I differ a bit on this last point, however. I think to use your premise XML is definitely the best choice for B [1] but I think that advocating XML as the best choice for A is futile and damaging. Because A as you say not only loves its
insights-du-jour but also loves to colonize them, it ends up saddling XML with A-flavored concepts such as strong data typing and lexically scoped namespaces with a terrible abbreviation scheme. Simon St. Laurent convinced me very early in the game, and I
remain convinced, that it's better to advocate the likes of ASN.1, JSON, protocolbuf, etc. for A in order to preserve XML's usefulness for the small group who do care about natural ambiguities and their expansion in the humane context. That would mean a much
smaller "market" for XML, but I think that's exactly what's needed.
[1] Actually I think MicroXML is the best choice for B as it tries to retain all the humane bits while slicing off the A-taint, but I suspect you'd probably disagree because it also strips away the last vestiges of DTDs.
--
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
| RSS 2.0 |
 |
| Atom 0.3 |
 |
| |
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|
Cart
