
XML, blockchains, and the strange shapes of progress - zdw
https://apenwarr.ca/log/?m=201809
======
rossdavidh
So, I saw something similar in semiconductor manufacturing in the runup to
Y2K. Lots of equipment that needed replacing, could not normally get replaced
because upper management didn't want to pay for replacing old equipment, then
wanted to spend only on shiny new fabs. However, Y2K was something that
shareholders cared about. So equipment vendors realized that if they said, "no
that old equipment cannot be Y2K fixed, however we can sell you an upgrade to
it that is Y2K compliant", then the engineers at old fabs could get some new
equipment finally. The engineers were happy to get newer equipment
occasionally, the vendors were happy to sell new equipment (or at least more
substantial upgrades) to old fabs as well as the new ones, and even management
was ok with it because no one got fired for doing Y2K upgrades. It all worked
well until Y2K actually came and went and then you couldn't use that trick to
get old equipment upgraded anymore.

~~~
Jeff_Brown
Amazing. It's like how forest fires can be good for forests.

------
fauigerzigerk
With a couple of bad metaphors you can prove almost anything. But anyway, the
point is blockchains (I guess).

 _> Consumers actually like transactions to be reversible, within reason;
markets work better that way. Companies even like to be able to safely unwind
legal agreements sometimes when it turns out those contracts weren't the best
idea._

Reversing financial transactions or contractual agreements in a way that
eradicates all traces of their existence is almost never what you want and it
is almost never legal.

If there is one truly append-only world out there then it is finance and
legal. I'm sure there are some exceptions, but it makes little sense to build
an argument on those.

I do agree though that blockchains seem like a rather contrived solution to
some of the problems they are supposed to solve.

~~~
hef19898
I still struggle to think of a blockchain application in the logistics and
supply chain domain that goes beyond trused digital customs docs and would
work. Maybe I lack imagination, but sometimes it reminds me of the RFID hype
back the day, only that with blockchain being digital, as compared to an RFID
chip, it attracts a lot more buzzword hunters.

------
dlubarov
> We can do consensus in many (much cheaper) ways.

Agreed, but that's why we're working on proof of stake systems. With BFT
algorithms, consensus can also be much faster, on the order of 1 second.

> Most people don't want their transactions or legal agreements published to
> the world. [...] And [companies] rarely want the public to know about their
> contracts, let alone their inventory details.

Also agreed, but that's why we're working on systems with better privacy,
using tools like ring signatures (Monero), zk-SNARKs (ZeroCash), Bulletproofs
(future Monero?), and zk-STARKs.

Private smart contracts are tough, especially if random access is needed, but
it's doable with a scheme like TinyRAM.

------
shady-lady
> We could have just as easily exchanged data with JSON (if it had existed) or
> CSV or protobufs or whatever

JSON & CSV, whilst undoubtedly simpler formats, still lack the 'power' of the
XML ecosystem.

Powerful tools to create a schema which can be used to easily view info about
data/validate data etc..

Interesting to see people try to use JSON for config aswell. That's never
going to end well.

~~~
enriquto
> JSON & CSV, whilst undoubtedly simpler formats, still lack the 'power' of
> the XML ecosystem.

"Power" is often a compromise. There are convincing arguments that plain text
is, after all, more powerful than JSON, CSV and XML. It all depends on the
context where this power will be exerted.

If you only need to store name-value pairs, it may be better (e.g., more
robust, more powerful) to use

    
    
        scanf("%s=%d", &name, &value);
    

than to depend on a particular json or xml implementation.

~~~
heavenlyblue
And then someone puts "=" in your key value.

~~~
enriquto
_Pray, Mr. Babbage, if you put into the machine wrong figures, will the right
answers come out?_

~~~
Thiez
So any url with url parameters (e.g. `?foo=bar`) are forbidden as values?
Seems like a rather big sacrifice to make for simplicity.

~~~
tannhaeuser
No, it's only forbidden as part of keys. Assuming newlines are used to delimit
the value, it's newline chars you can't use in values, though.

~~~
koolba
... and then your combine the two by saying that the text for the value is
JSON encoded so \n can be used for new lines.

------
tannhaeuser
Admittedly, I'm not really getting the main argument (that blockchain is like
XML in that it's overused, yet this is a good thing because it will bring
collateral progress?), but the bump on the broad misunderstanding of HTML,
SGML, and XML which has been ongoing since 2009 (and actually 1998) is worth
reading still.

[1]:
[https://news.ycombinator.com/item?id=490366](https://news.ycombinator.com/item?id=490366)
(2009)

------
DonHopkins
One important difference is that XML was never anything like the "get rich
quick" scheme that Blockchain and Bitcoin are today, so it didn't attract such
a huge number of charlatans and scammers. It was more of a "get shit done
quick" scheme, but it never attracted scum like Brock Pierce and his ilk, the
way Bitcoin does.

------
m-i-l
The differences between XML and blockchain are:

1\. Blockchain is being touted as a panacea, a solution to _every_ problem,
not just every data integration problem. This has led to all sorts of
companies offering solutions like retirment homes on the blockchain, massage
chairs on the blockchain, etc. etc. The scope of the claimed magical
properties of XML were never anywhere near as grandiose. I suspect this may
lead to a stronger backlash against blockchain.

2\. Blockchain is tainted, rightly or wrongly, by its association with
cryptocurrencies, and all the negative connotations that brings. XML never had
any association with large scale fraudulent activities. I can't imagine that
being helpful for continued large scale future investment.

As an aside, it seems some of the more serious formerly "blockchain" projects
appear to be rebranding themselves as "distributed ledger technology"
projects, perhaps to try to retain credibility.

~~~
r32a_
> Blockchain is being touted as a panacea, a solution to every problem, not
> just every data integration problem

Pretty sure that happens with every new tech.

> XML never had any association with large scale fraudulent activities.

I'm sure many criminal organizations have used XML

~~~
EvangelicalPig
You never heard business people going "Hurr durr XML Silk Road drugs" they way
they would with s/XML/Bitcoin

------
jancsika
> Bitcoin is like the XHTML of blockchains.

If XHTML had won you would not have had a bunch of web sites that wouldn't
render. You would have had browsers shipping both the old HTML parsers _and_
the XHTML parser, and attempting to send artisanal sites through the old HTML
parser before failing. Hell, you probably would have still had Hixie's
unifying algorithm for parsing the old HTML consistently across browsers.
Because consistency would have still been a problem for the billions of sites
that weren't XHTML.

If people had adopted Bitcoin instead of the old technology "X"\-- for _any_
"X" I can think of-- you'd end up with a vastly inferior product and a network
that probably performs several orders of magnitude slower than how "X"
currently performs. The only exceptions I can think of for "X" atm are funding
Wikileaks and funding Scihub.

So no, blockchain is not the new XHTML.

~~~
lucideer
This this this. If anything bitcoin is the new HTML5, though even that analogy
isn't great.

\- it's hugely popular mostly on the basis of hype

\- the technological advantages over predecessors is overblown

The analogy isn't great though because HTML5 largely succeeded on the back of
scaremongering the flaws of its predecessor, rather than bitcoin's success
being on the back of wild claims about its appropriateness as a technical
solution in so many applications. In reality, the two histories aren't
comparable.

~~~
beaconstudios
The html aspects of html5 have been hugely overblown, but css3 and the
totality of javascript apis that have spotted under the html5 banner have been
revolutionary.

~~~
SllX
“Works best in IE” has been replaced with either “works best in Google Chrome”
or “works best when you allow us to assault your computer with every tracking
script under the Sun”, usually represented by a blank page when JS isn’t
enabled, and especially notable when you were probably only expecting text and
images.

The revolution has been glorious. Can’t wait for the next one.

------
xte
I agree with author prediction, however I propose another solution: Plan9.
It's devs foreseen today's problem and start to solve them, far better than
actual partial solutions.

Oh, of course, Plan9 imply user independence and sovereignty a bad things for
today's "industry" so Plan9 solution rest buried in the past.

~~~
rakoo
Plan9 sure is a marvel of engineering because all interactions amount to
reading/writing a specific file, but it doesn't solve the issue that is
interoperability: it merely defines a way to connect to the remote service,
but it doesn't say what the _functional_ interface is.

\- what "files" should I read from or write to ?

\- what format should I use ?

\- when should I interact with said files ? Is it ok to tail -f it or should I
reopen it every time I want to get some new information ?

XML in itself didn't solve anything, it's the standards over how to define a
grammar and validate it that made all the interoperability.

~~~
xte
IMVHO there is a unnoticed problem underneath, probably best explained by XKcd
standard's vignette (927), we will NEVER really accept for long time "proposed
solution" but we can converge by nature to a common solution if we find a
comfortable common way to move.

Plan9 for me is an answer because yes, it does not solve problems you rightly
pointed out, but instead offer a common ground to reduce them by nature. It
offer a dramatically simple and effective "networked" solution so a good
ground on top of which we can develop a future of IT and so future
interoperable solutions.

Emails do the same, when they start, which means when we really have a
diversity/interoperability problem in communications: offer a means to develop
a common ground on top instead offer a "common solution to be adopted".

Every single product change, but needs tend to remain the same, Greenspun's
tenth rule of programming perhaps is another example that tell the same thing
better.

I hope to be clear, English is not my motherlanguage and so express
"philosophical" concept with it it's not easy for me...

------
hcayless
This is wrong in almost every detail, and superficial where not wrong. But the
underlying point, that we get useful things out of hype cycles even if they’re
essentially side-effects is true. I feel like there’s more skepticism about
blockchain than there was about XML, so maybe it won’t have the same sorts of
impact. On the other hand, maybe there’ll be a blogger writing pseudo-history
in 15 years arguing that we got Git’s versioning system because of blockchain,
so that’s nice.

~~~
purerandomness
Can you name one or two details that you think were wrong?

~~~
hcayless
Sure. XML is not in any way an evolution of HTML. XML DTDs are there because
one of the original requirements was backwards compatibility with SGML. You
can’t (well, really shouldn’t) parse an XML document without the DTD _if it
has one_ , because, thanks to entities, parts of the document might be in the
DTD. There wasn’t just one standards committee behind the whole W3C XML
activity, there were many. Some of them did indeed go out of control, but it’s
not fair to label them all that way.

JSON hasn’t, and won’t kill XML. it’s a simpler solution for most of the
things XML ended up being used for, but it’s pretty bad outside its comfort
zone. Companies that use it aren’t necessarily dinosaurs.

All that said, the author isn’t totally off base, just enough to annoy me on a
Saturday morning :-).

------
ThomPete
Our parents built the internet, our generations turned it into something
useful for the masses. I believe we are witnessing the same situation. Our
generation created the blockchain but it will be the coming generations and
the progress of technology which will find utility.

The blockchain doesn't "belong" to our generation just like the internet
didn't "belong" to our parent's generation even though they created it...
#Blockchain #cryptocurrency

We have too many endless debates about whether it's good or bad, a scam, to
energy intensive, too much skepticism, too many scars from believing in media-
hyped utopias or dystopias just to see them fail. The coming generations will
adopt it as if it's the most natural thing in the world and find ways to
utilize it we never thought off because they will be defining what has
inherent value to them. If you don't, believe that you have never experienced
how the art market functions or never heard kids discuss the latest skin or
emote in Fortnite...

Culture drives what we consider inherent valuable, not pure logic or academia
or Adam Smith. The blockchain is made for the digital culture and what will be
considered valuable (and thus per definition scarce) within that domain for
reasons still to be seen.

The blockchain is a protocol, protocols are infrastructure. The primary value
of the blockchain protocol is its ability to remember which is what gives it
it's "physical/atomic" properties. It's not decentralization as many believe
as that was already solved with the TCP/IP protocol.

So you can say it's like TCP/IP with a memory.

This also means that it's much harder to take things from the physical world
and apply the blockchain as that can still be compromised.

So instead of where it will shine is in things that are created in the digital
space. Crypto Kitties, Money, Digital Pokemon Cards, Documentation, Identity,
Marketplaces with digital assets etc.

Everything that has inception in the digital world.

------
Mc_Big_G
Yeah, blockchains, whatever. Cryptocurrencies are here to stay and if you
think bitcoin is the xml of crypto, you’re going to look exponentially dumb in
the coming years. Good luck with that.

------
jondubois
>> Blockchains solve centralization, which will turn out not to be the
problem.

Centralization is a huge problem. Centralization means that lots of smart,
hard working people essentially have to wait in line (sometimes forever) to
get access to capital in order to implement their ideas. Capital is so
centralized that decision makers don't have the mental bandwidth to invest it
effectively so most of it gets absorbed by useless institutions who do useless
stuff.

------
asenna
I would suggest the author to place long-term bets on those blockchain
predictions on the Augur prediction markets : )

------
jefecoon
From 1995 to 2002 I led biz dev for DataChannel's XML parser [ the first
written, most widely licensed to other platforms eg MSFT, and likely most
widely adopted ]. I coordinated our participation in XML & all the related web
services standards bodies.

We got to participate in a lot of amazing projects, whether relatively simple
open standards for DTDs that made it easy to interchange crisply [ eg MathML,
many others ], or for industries with considerable interchange challenges [ eg
SWIFT ]. These projects were typically fairly lightweight, and fortunately
many simply 'worked' and succeeded. In this capacity XML seemed to "just work"
and seemed to make the world a better place -- "victory!"

Of course you can't really discuss XML without discussing "Web Services,"
which is what many consider the "xml ecosystem." Around 1996 Norbert Mikula,
Mike Dierken, John Tigue, myself and probably a few other characters began
riffing on various ideas of how XML + HTTP could be used. What if you could
simply lookup a signed DTD for how your data was suppose to be delivered to
you? Lookup a signed DTD for how to invoke its API / RPC calls? Hell, why not
have a DNS-like directory of what services are available, whether on your
intranet, or from vendors? That's where the original 'whitepages / yellowpages
/ greenpages' naming convention in the very earliest days of web services came
from btw. Naive? Over-optimistic? Absolutely... But we didn't know any better,
so why not. We started discussing it with lots of smart people in SGML and XML
space, the concepts started turning into prototypes and it started to build
momentum.

People who were interested fairly wisely said "a standards body should lead
this stuff [ instead of some vendor ]," so the early work landed inside OASIS
[ the original SGML standards gangsters ]. Their wisdom gleened from long
years building incredibly complex SGML doc systems spared the early XML
services from many potential debacles btw. Momentum began to build, and super
interesting things started being built.

As Fortune500 IT, startups, middleware vendors and app servers became
increasingly interested in tapping in this magic a very interesting dynamic
changed: the platform players perceived all this interop, open standards as a
serious competitive threat.

Microsoft and IBM in particular got very involved very quickly, and the once
simple & elegant concepts quickly devolved into multiple competing standards
that were a horrible, illogical, impractical mess. This happened in less than
two years... Open-standards based web services essentially became an
irrational choice vs just "staying with your existing vendor's stack..."

That glimmer of amazing potential magic was quickly and effectively killed. Am
I saying XML & web services were perfect? of course not. I am saying a thread
of amazing potential was pulled, then around 1999 it was cut. And it was sad
to see first hand.

I hope GraphQL, JSON, the incredible variety of cloud services and other
interesting bits tap into that same magic.

Blockchain... imho interesting, but I fail to see many use cases where
business side buyers [ aka budgets ] __must __have a blockchain-based
solution. Looks like tech still searching for need and product /mrkt fit to
me... think long-term it offers many areas an interesting evolutionary step,
but I don't see it as hugely revolutionary gamechanging stuff.

Thanks for the walk down memory lane...

