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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] If XML is too hard for a programmer, perhaps he'd be bette

[ Lists Home | Date Index | Thread Index ]

> 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






 

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

Copyright 2001 XML.org. This site is hosted by OASIS