Next in thread → Next in month →

Re: [xml-dev] If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard

From
Liam Quin <>
To
Uche Ogbuji <>
Date
2003-03-31T21:04:41Z
ID
<>
Thread
Re: [xml-dev] If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
On Mon, Mar 31, 2003 at 01:48:09PM -0700, Uche Ogbuji wrote:
> > On Wed, Mar 26, 2003 at 10:13:40PM -0700, Uche Ogbuji wrote:
> 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.
It's OK, he wasn't very clear, but he did say "new" in there somewhere.

> 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?

No.

> > 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,

It's hard to do a round-trip transformation in those -- a typical constraint
is that you must not change the rest of the documents, including
* white space
* entity references
* cdata sections
so that a textual "diff" will show what was altered.

I agree with you that using a parser is better in general, but the point is
that XML is amenable to either approach.

Best,

Liam

-- 
Liam Quin, W3C XML Activity Lead, , http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
Ankh's list of IRC clients: http://www.valinor.sorcery.net/clients/
Next in thread → Next in month →