OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Parsing XML with anything but

On Tue, Dec 10, 2013 at 2:55 AM, Simon St.Laurent <simonstl@simonstl.com> 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.  

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.

Look programming is hard. Pretending that anybody can do it has never and will never help.

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.

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. 

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. 

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.

I would posit that this has nothing to do with stupidity, elitism, condescension, training or infinite complexity. 

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.

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.



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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS