"The syntax view" was Re: [xml-dev] [OT] Re: [xml-dev] Lessons learnedfr

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

On 11/17/13 2:19 AM, Hans-Juergen Rennau wrote:
> Simon and John dwell on a person's right to see somthing as he likes;
> Michael says that XML *is* syntax, and I suppose this is meant in the
> historical sense. I ask you to change the plain, abandon the social,
> psychological and historical, and focus on the technological.
Again, I must disappoint you.

My interest in markup is not purely technological, but rather about 
markup's being an almost unique intersection of humans and computers. 
Markup is a set of tools that lets humans gets directly in the 
information flow.  Computers are certainly still involved, but their 
role is minimized to the extent possible.

Understanding XML requires understanding the structures - human 
structures and technological structures - within which it operates.

> Let us
> investigate the various benefits of the alternative approaches. So you
> think I oversimplify things?
Yes. Utterly, and to my cost as well as your own.

> My view, in a nutshell, once more: XML
> technology is based on nodes, not syntax. Seeing syntax, I cannot deal
> with technology; dealing with technology, I cannot see (or should not
> see) syntax. And I take it for granted that we want to deal with
> technology. But it seems that things are not that simple and the "syntax
> view" offers something that has eluded me so far.
There are multiple ways to process and examine a given XML document, as 
Rick Jelliffe noted:

* Text
* Event streams
* Graphs of nodes
* Trees of nodes

The "syntax view" keeps the possibilities of that first option open.

* It reminds us that we are indeed 'marking up' documents that may have 
cohesive value on their own, not just as shredded and codified chunks of 
data.

* It recognizes that broken and incomplete documents may yet contain 
especially important information.

* It leaves the door open for information that didn't fit in someone's 
prized model, allowing for format evolution rather than cycles of 
standardization.  The structure of a given document is almost always 
easier to change than the programs that process it.  (The nodes view 
emphasizes the priority of programs and all too often celebrates the 
things that make them brittle.)

* It makes comprehensible possibilities that can't be reached if you 
lock yourself into nodes from the beginning.  Overlap is the place I see 
this most often.  Programmers indoctrinated into neat structure often 
see this as an utter corner case, but those who work with human 
documents know it exists regularly in the wild.

(It is certainly possible to create models for overlapping markup, but 
those models are substantially different from the models for simple 
trees or even graphs with clear boundaries.  Think of them as 
paralleling the shift away from Euclidean geometry by removing an axiom: 
that elements may not overlap, rather than that parallel lines may not 
cross.  The results are disconcerting but better reflect practice.)

I am sure I am missing something in this insomniac moment.  Others 
doubtless have different perspectives.

It's not just a matter of preference, "a person's right to see something 
as he likes".  I've watched the course of XML for the past 16 years.  I 
saw what began as a simplification process turn into a reinvention of 
tools that worked well in one context but poorly in most others.

The "syntax view" brings the humility to avoid those disasters as well 
as possibilities all its own.  It is rarely complete by itself, but the 
other modes are broken without it.

Which is a long way of writing "Your nodes are my tangle.  Your concrete 
wall [XML syntax, that is] is my freedom to innovate."

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