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

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

On 11/17/13 3:34 AM, Timothy W. Cook wrote:
> > 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.
> I think I understand your perspective.  Except, possibly what you
> intend to mean regarding 'information flow'.  Am I correct in that
> this is in regards from one person to another person via computerized
> text?
Not necessarily directly, but "among people, with computers in the 
middle" seems accurate.

(There are people using XML for strictly computer to computer 
communications, like sensors and controls, but I see no good reason now 
to celebrate bloat.)

> So, if I am correct in seeing your perspective that the purpose of XML
> (in your perspective) is to delineate (markup?) textual content into
> sections?  Also, that XML in its current and probable future state can
> do this for you in the way that you choose to use it?
Yes.

> Can you *PLEASE* tell me how the fact that XML has other components
> that addresses other uses cases outside your own use case, harms you
> or your work in any way?
>
> IOW: If you are not forced to use XSD or namespaces to accomplish your
> goals with XML.  Why are you so adamantly against them when they are
> useful to other people in different use cases.
Well, for starters, I get to waste hours of time explaining to people 
who've been brainwashed into thinking that XSD and namespaces are the 
One True Way of XML that there are other options.  Even here, that's a 
surprising ordinary case.  (Why am I writing this for sixteenth or so 
time on a Sunday morning?)

Those tools and the lessons they've taught make it extremely difficult 
to convince people to take another look, especially when the lessons 
they've taught people are to run screaming away from XML and not look back.

For a while, I figured that the XSD/Namespaces/etc. stuff would be fine, 
just not for me.  Other people clearly do have different use cases. 
Then, thanks to my weird position as a writer, editor, and known critic, 
I had lots of people telling me about how those tools were seen as the 
ruin of entire projects.  The stories added up too well.

I heard similar stories about XSLT, but at least in those cases I could 
_usually_ identify where XSLT had been the wrong tool for the job. 
XSD/Namespaces stories were reliably about specifications gone brittle, 
priorities set badly by people seeing different pieces of the same 
schemas, and waterfall processes that made it hard to correct these issues.

That doesn't mean there aren't use cases where XSD/Namespaces/etc. do 
apply and can succeed.  Nor does it mean that my case is right.  It 
does, however, make me marvel that the folks pushing XSD and Namespaces 
go right on doing it as if they weren't selling toxic waste.

So yes - an answer you probably won't like.  XSD and Namespaces have 
made the XML ecosystem toxic.  "It works for me" gets repeated here like 
"Every day in every way I get better and better" gets repeated by the 
self-hypnotists of the Coue method.

That's a lot of why I talk about markup in most contexts, and avoid 
talking about XML unless it's to an XML audience or reached that level 
of specificity.

> I have asked questions on this list about XML technologies that are
> specified and are in common use across domains.  Hoping to get answers
> from people with more experience in XML.  Like you, I know my domain.
> I can make the decision whether or not XML technologies are a good
> fit, if I can get technological NOT philosophical answers.
If you don't want philosophical answers, perhaps you should ask your 
programs instead of people?

Take a look at your foundations again.  They're getting more brittle all 
the time.

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