- From: Ian Graham <ian.graham@a...>
- To: xml-dev@l...
- Date: Sat, 8 Jan 2022 11:19:14 -0500
You could argue there are well
defined 'test criteria' with a language upgrade: recompiling
the program (test #1) and, if that is successful, testing the
program works correctdly (test 2), sometimes using test suites
integrated with a program package .
'Easy' for a program having well
defined dependencies, not easy for data interchange.
On 08-Jan.-22 10:23 a.m., Peter
Hunsberger wrote:
XML is used for the interchange of data,
programing languages are not dependent on the input or output
of other systems (though the programs they produce might be).
Thus, there is no network effect for a programming language, I
can upgrade the version of a language I am using without
impacting any other part of the ecosystem.
Programming languages manage to change, grow
and sometimes even lose features all the time.
If it is possible for programming
languages, why should it be impossible for XML?
And if there is a technical reason (such
as the under-specification of the semantics of the
version psuedo-attribute in the header) can it be fixed
first, propagate out and open things up again?
Rick
The other major influence is the
"network" effect. For TCP/IP, it was easier and
cheaper to use than Token Ring, so it crept into more
places faster and once that happened it made no
sense to have multiple standards. The same
thing happened with JSON; _javascript_ became widely
available on the browser, so using some _javascript_
like datatype to work with the server was extremely
compelling. Once that happened why use another data
format to connect your server to other servers? You
already had something that worked well enough for data
transport. The major difference here is that XML and
JSON can coexist much easier than TCP/IP and Token
Ring so it wasn't an all or nothing victory in the
case of JSON.
The network effect also helps explain why we
haven't seen much evolution in XML even where it is
established. Unless the changes can be backwards
compatible it usually impacts your entire ecosystem
to make a change, it's rarely a point to point
change and even when it is, you have to own both
sides of the data exchange to make it happen. Yes,
API versioning happens all the time, but this is
much deeper, you can't just add another endpoint,
you've got to have frameworks designed to support
multiple serializers and in the world where XML grew
up that was extremely rare. At least until JSON
came along, but now you've got JSON so who needs
another version of XML? The XML serializer is there
just to talk to that old mainframe in the corner
that nobody is ever going to touch...
On Fri, Jan 7, 2022
at 3:16 AM Michael Kay < mike@s...>
wrote:
Some excellent points here from Rick and Alexander.
I think with most technologies/standards we tend to
see
(a) an era of experimentation, where lots of people
invent new things
(b) followed by an era of consolidation, where a
small number of winners emerge
The number of winners after phase (b) is highly
variable. With database technology, it got down to
one (SQL). Similarly with the networking stack
(TCP-IP), and the web (HTTP / HTML / CSS / JS), and
character sets (Unicode). With operating systems it
got down essentially to two (Unix / Windows). In
most of these cases there were epic contests before
winners emerged. With procedural programming
languages it never got down to less than half a
dozen, though Java looked like a promising
convergence point for a while. Some other
technologies, like 4GLs and NoSQL databases,
withered on the vine primarily because they failed
to achieve this convergence.
The forces that determine whether convergence
happens and how long it takes are essentially a
battle between the desire for innovation and the
desire for interoperability. (The pressure for
innovation comes primarily from vendors who want a
USP rather than from users who want new features, of
course).
Once consolidation is achieved, things tend to
remain stable for a very long time: it becomes very
hard for anyone to break the consensus. If a
breakaway does occur, it's most likely to emerge
from a niche, or from some technological disruption
(voice over IP, say). If anyone ever breaks the
50-year-old duopoly of Windows and Unix, it will
probably be some operating system designed for a
niche market.
So where does XML fit in this picture? Until 1998
there was a very long period of experimentation;
there were some standardisation candidates (SGML,
ASN.1, EDI) but by and large, the scene was highly
fragmented. The convergence on a single standard was
unusually sudden, and I've always been puzzled as to
what exactly were the industry dynamics that led to
such an explosion of rapid adoption: one of them
undoubtedly was the low cost of implementation and
adoption. But I think that the very rapidity of this
adoption also meant that the consolidation phase was
an unstable equilibrium: because it was the only
game in town, people embraced it a bit too eagerly
for things it was never designed to do. Unlike
databases, operating systems, and character sets,
it's an area where the benefits of doing something
different can exceed the costs, so it was easy for a
breakaway niche such as JSON to emerge.
When a breakaway occurs, it's usually a technology
that's simpler, less capable, but better suited to
the needs of people who need something simple. The
old guard maintaining the consensus thus tend to
dismiss it as kids' stuff. This ignores the lesson
that progress is often achieved by stripping out the
debris of complexity that accumulates over time, and
starting afresh with a clean sheet of paper.
Michael Kay
Saxonica
> On 7 Jan 2022, at 05:37, Alexander Johannesen
<alexander.johannesen@g...>
wrote:
>
> Stephen D Green <stephengreenubl@g...>
wrote:
>> I think JSON succeeded because it was
already existing and got discovered so it was free
>> and already had traction and some sanction
as part of _javascript_.
>
> Let us all not forget that there was a huge
shift in data usage,
> control and manipulation from the old days of
powerful servers and
> rubbish browsers, to the new world of
all-singing-all-dancing
> standardized browsers of speed and power. JSON
came with that new
> platform when XML wasn't looking.
>
> I've spent my whole life on both sides of this
chasm, and, well, I
> certainly wish that smarter people could create
an XPath-like
> implements (right in JS/TS itself, not as yet
another bloody
> library...) for JSON (all the current libraries
are ... umm, not in
> the ballpark of what's needed ... I used to be
an XPath wiz, and look
> at me now *sigh*) both for schemas as well as
object/data access.
>
> Because all the smart heavy-hitters on the
backend were too busy with
> XML (making it more bloated and complex), the
lighter punters on the
> browser side forgot the typification aspect in
JSON. Damn, we were
> *this* close!
>
>
> Cheers,
>
> Alex
> --
> Information Alchemist, tone modulator, swords
master
> thinkplot.org
|
linkedin.com/in/shelterit |
sheltered-objections.blogspot.com
>
>
_______________________________________________________________________
>
> 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
>
_______________________________________________________________________
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]
|
Cart
