[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: seduced by markup

  • From: Michael Sokolov <msokolov@safaribooksonline.com>
  • To: Steve Newcomb <srn@coolheads.com>
  • Date: Fri, 15 Nov 2013 16:46:11 -0500

Re:  seduced by markup
On 11/15/2013 04:32 PM, Steve Newcomb wrote:
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

Thanks, Steve. I guess Pete's dichotomy of pot-smoking hippy vs. OCD might not have a category for you! I was merely pointing out that there are markup dogmas and there are programming dogmas. Both are probably born out of valid concerns. I do agree that human concerns are often more important than efficiency or processing concerns, but human concerns are also often petty and/or political, and sometimes need to be informed by practical considerations, like ease (or possibility) of implementation given a set of constraints.

Also, it's besides the point -- and maybe I misunderstood you -- but I doubt we would have a working healthcare system even if the ACA web app worked fine. The ACA is a band-aid, or maybe a first step, in my view -- it doesn't go nearly far enough. But that's waaay off-topic. sorry.

-Mike



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.