Re: [xml-dev] seduced by markup

[Steve Newcomb <srn@coolheads.com>]

On 11/15/2013 03:29 PM, Michael Sokolov wrote:

> There's [obsessive-compulsive disorder] stuff in the XML world too, and it was there right from the
> start, it just has a different flavor: DTD. The whole "DOCTYPE must be
> conveyed with the document" religion created the concept of a document
> that isn't complete without being processed by its accompanying DTD. 
> The result is a programmer's nightmare, but makes sense to a certain
> kind of document purist.

You can call me disparaging names like "document purist" and "OCD
sufferer", but I have quite a different perspective on these things.

The W3C completely misunderstood SGML's single most important feature
when they dismissed the DTD formalism from their thinking about XML.
The DTD syntax was never about machines.  It was about human beings, and
it is still, even today, and as crummy as it is, the most humane way
available for human beings to communicate about data design in a diverse
collaborative environment that inevitably must include non-programmers.

It was, and it remains today, a fantastically costly error to think that
software could ever fill the role that the dread <!DOCTYPE... *still*
plays in the real world.  Whose software?  Running in whose environment?
 Who gets to edit the product of the discussion?  What is the tangible
form of the product under discussion?  How do you phrase a question that
was unanticipated by any software's design?  How do you train every
stakeholder in the deep magic of the software, sufficient to allow
everyone to pose a problem or solution?  Summarize conflicting
positions?  Craft a technical solution to a political problem?  Create a
technically stable, predictable, toothy agreement out of chaos?  Do
eye-parsing in a fractious, sweaty committee environment, so at the very
least everyone can plainly see what they're arguing about?

Consider what would have happened if, even as little as 2 years ago, all
the stakeholders in the ACA rollout were given 6 months to agree on the
structure of the information that they were supposed to interchange,
with the result being a set of DTDs.  I claim that today, at the very
least, we would all know exactly who the actual sabotageurs, deadheads
and incompetents in our midst are.  And we would likely have a working
(albeit, um, suboptimal) healthcare system in the U.S.  There is nothing
like compact text that human beings can parse with their eyes,
regardless of whether they know anything about text processing.  That's
what the DTD formalism *still* provides today.

If the purpose of a programmer's task is to make machines facilitate
human communication, nobody should care how hard that task is, least of
all the programmers.  While laziness is definitely a virtue in
programmers, the stovepipe priesthood is merely vicious when it
sacrifices the purpose of the task on the altar of its own convenience.
 Len Bullard was very correct to point that out, although his euphemisms
didn't put it as plainly as I put it to you now.  Human communication
(and there's no other kind of communication) is an extremely demanding
mistress.  She withholds her favors readily and often, but not at all
capriciously.

By the way, I still program every day for a living, and I spent almost
two decades of my life developing international standards for data
processing in tough, sweaty committee environments.

Steve Newcomb