[BangPypers] parsing xml
lorddaemon at gmail.com
Fri Jul 29 11:37:41 CEST 2011
> Along the same lines...the problems are more when xml is concerned, for even
> if some other tag is malformed, then the
> whole document is 'gone'.
Well, then - the API is broken and is basically violating the TOS for
the API (which I would at a minimum expect to return valid output or
the appropriate HTTP error code). How defensive do you get about all
the 3rd parties that are violating your TOS? Defensive enough to not
use a standard like an XML parser + XPATH?
If the XML itself isn't malformed, but the XML document has changed
(not unusual with document oriented services) then that's exactly why
you'd want to use a more tolerant lookup scheme like XPATH.
Anyway, when in doubt, I say look up c2.com.
http://c2.com/cgi/wiki?RegularExpression - just do an in-page search
for the comments on XML.
* Be clear whether you're simply picking text out of the file or parsing it.
* You can't parse XML with regexps
* If you're doing a simple pattern lookup, why use XML? Clearly you
don't care about the document structure.
On Fri, Jul 29, 2011 at 11:54 AM, Venkatraman S <venkat83 at gmail.com> wrote:
> On Fri, Jul 29, 2011 at 11:31 AM, Noufal Ibrahim <noufal at gmail.com> wrote:
>> > I am a speed-maniac and crave for speed; so if the assumption is
>> > valid, i can vouch for the fact that regexp would be faster and neater
>> > solution. I have done some speed experiments in past on this (results
>> > of which i do not have handy), and i found this.
>> Premature optimisation is the root of all evil.
> I belong to a different school. I think about performance right from the
> design dashboards for i think, be it a simple webapp or a financial
> application, the choice of your design patterns and techstack goes a long
> way in a good customer experience. Bulk of my thoughts are reflected in here
> : http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html
> I generally lay emphasis on 2 things when it comes to webapps : 1) Layout
> and 2)Speed. I am ready to sacrifice certain features; if i think a certain
> feature will cause some issues with customer experience(after all we are
> developing apps for the customer and if he is made to wait for 5s for an
> events, then its bad), i would rather not present it or present in some
> 'other' fashion(like a batched job?).
> BangPypers mailing list
> BangPypers at python.org
More information about the BangPypers