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

Re: If XML is too hard for a programmer, perhaps he'd be bette

• To: Liam Quin <liam@w...>
• Subject: Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Mon, 31 Mar 2003 13:48:09 -0700
• Cc: xml-dev@l...
• In-reply-to: Message from Liam Quin <liam@w...> of "Fri, 28 Mar 2003 10:54:13 EST." <20030328105413.A20785@w...>
• Sender: Uche Ogbuji <uche.ogbuji@f...>

> On Wed, Mar 26, 2003 at 10:13:40PM -0700, Uche Ogbuji wrote:
> > BTW, I find the idea of processing XML using simple regexen pretty hair 
> > raising.
> 
> Luckily that's not what Tim was talking about at all. I'm guessing you
> have not yet read about Perl 6 regular expressions :-)
> 
> Perl 6 "regular expressions" are actually full-blown grammars, with an
> new and massivley clearer syntax.  And that's what he referred to.
> It's more like having a more flexible and more powerful YACC interpreter.

I'm sorry, but I didn't read anything about any specific version of Perl in 
Tim's article, and my impression was that he meant simple regexen.  Or are you 
seriously meaning to put in Tim's mouth that it would be easier to write a 
YACC-like parser on your own than to re-use an existing XML parser?


> None the less, it's worth noting that one of the use cases for XML from
> the beginning was the "desparate perl hacker" who had to change, say,
> part number 1976 to 3072 in 100,000 documents without affecting dates,
> and had an afternoon to do it.  That specific use case was achieved in
> practice for most people.

I don't dispute that the use case was met, but I think the use case is as well 
met by using, say Python/DOM/generators as it is using regexen, and I'd feel 
*much* safe about the former class of solution.  If I had to vouch to he CEO 
that I had converted the dates in those 100,000 files without corrupting any 
data, you wouldn't catch me anywhere near a regex hack for basic parsing.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Use internal references in XML vocabularies - http://www-106.ibm.com/developerw
orks/xml/library/x-tipvocab.html
Universal Business Language (UBL) - http://www-106.ibm.com/developerworks/xml/l
ibrary/x-think16.html
EXSLT by example - http://www-106.ibm.com/developerworks/library/x-exslt.html
The worry about program wizards - http://www.adtmag.com/article.asp?id=7238
Use rdf:about and rdf:ID effectively in RDF/XML - http://www-106.ibm.com/develo
perworks/xml/library/x-tiprdfai.html
Keep context straight in XSLT - http://www-106.ibm.com/developerworks/xml/libra
ry/x-tipcurrent.html
Using SAX for Proper XML Output - http://www.xml.com/pub/a/2003/03/12/py-xml.ht
ml
SAX filters for flexible processing - http://www-106.ibm.com/developerworks/xml
/library/x-tipsaxflex.html

• Follow-Ups:
  • Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
    • From: Liam Quin <liam@w...>

• References:
  • Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
    • From: Liam Quin <liam@w...>

• Prev by Date: Re: If XML is too hard for a programmer, perhaps he'd b e better off as a crossing guard
• Next by Date: RE: XML into SQL and out again
• Previous by thread: Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• Next by thread: Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• Index(es):
  • Date
  • Thread