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

["Toby Considine" <Toby.Considine@gmail.com>]

Decentralized decision making is good. A resilient future likely requires
diverse technologies interacting with their own internal algorithms, able to
develop rapidly without waiting for central committees and universal (hah!)
approval.

But 

Do you document the interfaces/messages  that you use internally, even if
only for yourself?
Do you write down the assumptions you make, and what might be an error, even
if only for yourself, when you come back in a year?
Is any of this documentation machine readable, to be consumed by your tools?

And when you get hit-by-a-bus (or take another job, or get bored and open a
goat dairy) what happens? Or if you do not care (because you'll be off with
the goats...), how do you feel about keeping those systems working when the
person you rely on when exchanging forbidding stray notes, or answering
out-of-band queries, or who has said something completely different from the
vocabulary you've chosen leaves to be a maker of goat cheese...

A culture of innovation a culture of compliance, or even a culture of
straight-jacketing can all exist whether or not we use standard schemas.
Standard schemas can coexist with ad-hoc schemas. As long as we avoid those
zealots (and I know them, too) who want to extend their one schema or
information model to be used in all other spaces, whether they fit or not,
then the standard specifications add great value. An overbroad
specification, or a minimal standard badly applied, can certainly reduce
productivity and creativity. A minimal standard, well used, enhances
creativity.

As Ed Crowley observed long ago, "There are seldom good technological
solutions to behavioral problems". You seem to be focusing on behavioral
problems, which can be endemic in certain organizations, and on the misuse
of specifications.

tc

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent: Monday, March 25, 2013 9:02 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Not using mixed content? Then don't use XML

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/

_______________________________________________________________________

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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php