This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Eugene Miloslavsky <miloslav@get.topica.com> From: David Lowe <dlowe@pootpoot.com> Subject: Re: [sf-perl] validating XML parsers in Perl? Date: Wed, 25 Jul 2001 12:12:57 -0700 (PDT) Eugene et. al. - search.cpan.org says the following might be worth looking into, but I don't have any experience with any of them... XML::Checker XML::Schematron libxml-enno-1.05a === To: sfpug@sf.pm.org From: Roman Brenes <romanab@pacbell.net> Subject: Re: [sf-perl] validating XML parsers in Perl? Date: Wed, 25 Jul 2001 13:25:16 -0700 <QUOTE> Xerces.pm is the Perl API to the Apache project's Xerces XML parser. It is implemented using the Xerces C++ API, and it provides access to most of the C++ API from Perl. Because it is based on Xerces-C, Xerces.pm provides a validating XML parser that makes it easy to give your application the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents. Xerces.pm is faithful to the XML 1.0 recommendation and associated standards (DOM 1.0, DOM 2.0. SAX 1.0, SAX 2.0, Namespaces, and Schema), The parser provides high performance, modularity, and scalability. </QUOTE> http://xml.apache.org/xerces-p/index.html === To: sfpug@sf.pm.org From: zenji@gmx.net Subject: Re: [sf-perl] validating XML parsers in Perl? Date: Thu, 26 Jul 2001 01:10:36 +0200 (MEST) > <QUOTE> > Xerces.pm is the Perl API to the Apache project's Xerces XML parser. It > is > implemented using the Xerces C++ API, and it provides access to most of > the > C++ API from Perl. > [...] > The parser provides high performance, > modularity, and scalability. So it's a wrapper to C code implemented using XS, but it "provides high performance"? It could be true, but I'd say caveat emptor if performance is a key consideration. === To: sfpug@sf.pm.org From: mehryar <mehryar@mehryar.com> Subject: Re: [sf-perl] validating XML parsers in Perl? Date: Wed, 25 Jul 2001 16:34:24 -0700 (PDT) > So it's a wrapper to C code implemented using XS, but it "provides high > performance"? It could be true, but I'd say caveat emptor if > performance is a key consideration. > --Q > anecdotally, XML::Lib(XML|XSLT) seems to be pretty fast, I thought I saw benchmarks some where but I cant recall where. http://aspn.activestate.com/ASPN/Mail/Message/677331 === To: sfpug@sf.pm.org From: David Fetter <shackle@fetter.org> Subject: Re: Jay Stanley: Re: [sf-perl] [OT] SQL question Date: Thu, 26 Jul 2001 20:15:06 -0700 On Thu, Jul 26, 2001 at 06:20:35PM -0700, Joe Brenner wrote: > This is what I get for trying to rely on the O'Reilly book, "Oracle > SQL The Essential Reference". This is definitely not one of the > good O'Reilly's... You might want to try Oracle: The Complete Reference (whatever the latest one is) from Oracle Press. Cheers, D (yeah, PL/SQL *still* doesn't do regex's, but it's pretty cool anyway) === To: sfpug@sf.pm.org From: David Fetter <shackle@fetter.org> Subject: Re: [sf-perl] [OT] SQL question Date: Thu, 26 Jul 2001 20:39:44 -0700 On Thu, Jul 26, 2001 at 05:34:54PM -0700, Kirit Sarvaiya wrote: > You're right. PL/SQL (faster) or Perl would have to be employed. Not really. cf. correllated subqueries. It's possible that PL/SQL would give lightning-fast performance, as in orders of magnitude better in some cases, but let's look at what the query is actually doing. Is it *really* worth it to spend a bunch of coding hours to pico-optimize something that runs maybe once a month and does, at worst, one cartesian product of two tables, one of which (sales) is small and the other (emp) of at most the same order of magnitude? Unless people are having major problems with this, the answer is a resounding no. > Which is why.... > SQL = Structured QUERY Language > PL/SQL = Programmable Language/Structured Query > Language > perl = Practical Extraction and Reporting Language > (amongst others) and this silliness is why people say that a little knowlege is a dangerous thing. SQL can do UPDATEs based on the results of any SELECT it can do, and has always had this ability. Cheers, D (but we all learned something neat, and that's what counts :) ===