Altova Mailing List Archives


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

From: Uche Ogbuji <uche.ogbuji@-----------.--->
To: Liam Quin <liam@--.--->
Date: 3/31/2003 9:22:00 PM
> 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.

Phew!  OK.


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

OK.  I wasn't getting this point before, and it's a good one.  Of course, I'd 
be much happier if more lexically rich XML APIs were the norm, but I think 
that would tend to make them *harder* and not easier for developers, so I 
think that's really a branch off to a different thread.

On that thread somwhere would be my wishing that Simon would some day find it 
in his heart to port his experientations to Python :-)


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

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.