Re: [xml-dev] Parsing XML with anything but

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

On 12/9/13 11:25 PM, Ihe Onwuka wrote:
>     No, you can't do any of those things.  However, there is an enormous
>     class of tasks for which those issues simply do not matter.
>
> What about the enormous class of tasks for which the built in default
> rules of  XSLT combined with inheritance (sorry I meant xsl:import -
> tomayto tomarto) are ideally suited but the language is not used.
People frequently don't use XML tools because we've (myself included) 
done an incredibly poor job over the years of presenting and explaining 
them.  They integrate them with their own systems, find that they aren't 
a neat fit with what they expected, and use them minimally or drop them.

Then they're rewarded - if they ever look at this list, which is 
fortunately more and more likely - with remarks about "don’t have the 
inclination, patience or capability to fully understand your language of 
choice."

>     I get that people on an XML list freak out when people don't follow
>     all the rules we think we've established.  We need to find a better
>     way to handle our freaking out than sputtering about "either stupid
>     or poorly trained" people who "don’t have the inclination, patience
>     or capability to fully understand your language of choice."
>
>     It makes us look bad, not them.  It hurts our cause(s), and doesn't
>     help theirs.
>
> Ok, I deliberately avoided pointing out that you were the one who
> introduced the word stupid into the discussion. I can see that was an
> error because you have repeated and layered the word condescension on
> top  of it. Voila that is now  the barometer for judging the alternative
> argument.
It's terrible when people summarize a post that punches down by calling 
it critical of the people it was punching down at.

I get that it's hard to see the damage inflicted by such punching down 
when you think you're on the up side of the argument.

> Look programming is hard.
Yeah, I get that.  I've been teaching programming for the past how many 
many years?  In person, via books, via other people's books.  If it was 
easy I would probably have found something harder to explain.

Part of the challenge, though, and a strange feature that's done well 
for me over the years, is that few programming communities are good at 
explaining what they do.

Many even pride themselves on welcoming outsiders but then drown them in 
expectations of vocabulary and best practices.  Then they puzzle over 
what's wrong with the people who were trying to come in.

> Pretending that anybody can do it has never
> and will never help.
"Anybody can do it" completely depends on the context.  We are not 
breaking new ground like Donald Knuth any more.  A few core people need 
potent skills to write, for example, transformation engines, but most of 
it is more tractable for a much wider group of people.

XML was supposed to make all of these problems more tractable, for 
people who were not super-programmers.  Hence the DPH, hence the effort 
to reach a broad world.

That effort failed, and now we sit here talking about how the common 
tools are the wrong tools and people who "don’t have the inclination, 
patience or capability to fully understand your language of choice" - 
their language of choice - of course can't be trusted to deal with XML.

> The stupidity and condescension arguments are complete red herrings -
> clearly the people who build these XML parsers aren't stupid and the
> many people  who use them aren't either. It's a real shame you
> introduced such perjorative terminology to advance your argument (wonder
> why) because it has had sidetracked and had a deleterious effect on the
> quality of discussion.
The original post was perjorative - I deleted the word "obnoxious" from 
my earlier posts repeatedly.  It will make a nice exhibit A for future 
conversations about how the stories the XML community tells to dismiss 
concerns about its viability.

>     That attitude is exactly why I've largely given up speaking about
>     XML to broader audiences and retreated to "markup".  It doesn't
>     carry the elitist baggage or visions of infinite complexity.
>
>
> Ok well you have a different level of concern. The Fowler link I posted
> about Ruby being better than XSLT for parsing  didn't make reference to
> elitist baggage or infinite complexity. The thing that popped into my
> head when reading it was the same thing that pops into when I read
> similar complaints and expressions of frustrations of people far less
> accomplished.
I liked your earlier comment on Fowler about choosing solutions when you 
hire a consultant.  That part is completely true.

However - and I last talked with Fowler in 2005? - it seemed pretty 
clear that his antipathy to XML came from its promising to be a simple 
silver bullet and then perpetually adding layers.  It's been a while, so 
the details are fuzzy, but even at the time I was nodding my head and 
apologizing for our screw-ups.

> Do you know the built in default processing rules Martin? Alas he never
> mentions if he does. It is completely understandable that XSLT will seem
> a pointless anachronism to anybody - no matter how smart - if they don't
> know these rules.
These rules are the magic of XSLT.  Invisible but omnipresent and 
powerful.  Magic has pluses and minuses - they make things easier if you 
either know what you're doing completely or are willing to follow 
recipes precisely.  Magic slashes you to bits if you don't understand it 
completely or stray from the recipes.

(I didn't understand that problem well until I spent too much time with 
Ruby on Rails.  Magic that keeps changing and introduces security issues 
makes the difficulties more visible, of course.)

> So the next question is how hard is it for people to know these rules.
> There are how many - 7? - ok on or just above  the upper limit of what
> we can expect people to remember  - but the Gods were merciful and
> alleviated our pain somewhat. They made the defaults do the thing we
> were most likely to want to do and them conceptually similar to the
> dispatch mechanism of OOP and everybody understands that - right.
Unless, of course, default namespaces were involved, and then things 
derailed every time a new person joined the conversation.  This appears 
to have been the Gods' punishment to the XSLT community, 
counterbalancing the generosity.

> I would posit that this has nothing to do with stupidity, elitism,
> condescension, training or infinite complexity.
The rules themselves have nothing to do with those, except perhaps the 
last.  However, our responses to the rules, the human responses upon 
which things get done or do not get done, include all of those.

Programmers like to think programming is a neat test of logic and 
ability to follow the rules set forth by humans and the 
language-creation priesthood. (The acolytes create frameworks, I guess.)

The rest of the world understands that programming is about interactions 
among humans, with computer interactions only one small part of the 
conversation.

> Rather it comes down to whether or not one knows the built-in default
> rules. In turn that invites the question whether they are onerous to
> learn and whether it is reasonable for a DSL to have such idiosyncrasies
> (isn't that what makes it a DSL). Then it's  whether or not going off to
> build or use a parser from a general purpose language is a reasonable
> response to not being willing to learn the built in rules. If you knew
> 'em fair enough - but I'd like to think that to know them is to love them.
This last sentence has been XML's recipe for initial success and then 
repeated failure.  "Just a few rules," we say, "and you'll like them. To 
know them is to love them."

We say that because we like them - because we've internalized the 
benefits and forgotten the costs.  Well-formedness isn't hard - "just 
stay away from creating XML with text-processing tools and you'll be 
fine."  Namespaces aren't hard - just don't touch the stove in those 
places when it's on.  XML Schemas are hard because the world is hard and 
they need to be powerful.  XSLT only has a few issues...

XML had a strong start, with lots of people liking the capabilities and 
many even the rules.  The XML community has not found such success since 
the early days, however.

> The other interesting element is the declarativeness of the language as
> the the roll call of declarative languages that achieved widespread
> acceptance has a length of (going out on a limb here) 1.
>
> SQL.
2.

You forgot the one that squashed XSLT's initial hopes: CSS.  Utterly 
declarative, though so far thankfully not aiming for Turing-complete. 
Occasionally hated for its declarative nature by programmers, cursed 
with a limited (but now finally changing) layout box model, but used 
constantly by people from skill levels from beginner to superstar.

(Proving to be a solid foundation for people who want to create more 
powerful languages on top, too.)

We need to stop wondering why people don't want to use 'our' tools and 
start figuring out how to reach them.  Or, if we prefer, we can spend 
our time on endless iterations of this thread, stewing in our own 
greatness and wondering why it is that people from cut-and-paste coders 
to well-respected consultants don't grasp the power and beauty that is 
the XML family of specifications.

That last is unfortunately a permathread here.  I should stop poking at 
it - the battle seems pretty much lost to me in any case, at least as 
far as the XML moniker goes.  I just don't love the toxins it 
periodically produces, as here.

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