Re: [xml-dev] Not using mixed content? Then don't use XML

["Simon St.Laurent" <simonstl@simonstl.com>]

On 3/25/13 12:24 AM, daniela florescu wrote:
> However,  Simon!
>
> I think you are totally wrong about the only use of XML being mixed
> content.
>
> Another major reason of why people do use XML (and will continue to
> do so) is the need for standards, for legal reasons.
>
> If the Navy bombards the wrong city because of a wrong NavyXML
> message, they can point and blame the precise origin of the error:
> e.g. an extra digit character in a geolocation attribute or such.
>
> If a patient dies in a hospital because of bad blood work they got
> from another hospital, you know exactly who is at fault, and why the
> message was wrong.
>
> THAT'S the major reason of why people use XML right now.
>
> People need legal reassurance.

It may be a major reason, but it reveals flaws in our people and
organizations rather than strengths in our technologies.  Catering to 
those flaws has weakened the solutions we offer.

We are so deeply broken that we cannot imagine proceeding without some
kind of binding - often suffocating - agreement before we even get to
solving problems together.

In our brokenness, we've spent decades encouraging people to create
standards first.  Too many of us have assumed that this was the only way
to support reliable communications, assuming that unless everyone
marches together to a beat set at the beginning, we'll all wander off 
and hurt ourselves or others.

In our quest to to automate systems, we've discarded the human
flexibility that used to keep those systems working, forbidding stray
notes, out-of-band queries, and the times when someone might need to say
something completely different from the vocabulary we've chosen.

Worse, we have taken expectations that might have applied amidst the
paranoias of corporate and government bureaucracies (think $GML: The 
Billion-Dollar Secret) and pronounced them appropriate for ordinary work 
at every scale.

We have blinded ourselves to rather obvious notions of local
error-handling to prevent these worst-case scenarios, and insisted that
only central architects (or committees of architects) have the wisdom to
prevent such catastrophes from happening.

In kinder moments, as above, we speak of finding violations of these 
rules as an excellent way to place blame, forgetting about all of the 
opportunities we neglected along that path for better outcomes to emerge.

So what can we do?

We can pause for a while and try to imagine other ways of doing things. 
  It may be a long pause, as these practices are deeply engrained in our 
community.  (It was years for me.)

We can separate the practice of markup from the practice of agreement.

We can study the places already existing in our field where people found 
that a particular variety of markup failed to meet their needs, and 
cobbled together solutions that retained some interoperability while 
adding flexibility.

We can look outside of XML to those people who are doing all the things 
that make us feel unsafe, and study the ways it works (and yes, doesn't 
work) for them.

We can experiment - perhaps at first in places that feel safe - with 
approaches that decentralize decision making, encourage rapid iteration, 
and evolve toward stability if and when it fits user needs.

Or we can stay in our cozy little niche, building walls for people who 
find that walls make them feel safer.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/