Mailman 3 May 2007 - lxml - The Python XML Toolkit

[lxml-dev] first take on an lxml.etree tutorial
by Stefan Behnel 16 May '07

16 May '07

Hi everyone, I finally found some time to get started on a tutorial for lxml.etree. http://codespeak.net/lxml/dev/tutorial.html http://codespeak.net/svn/lxml/trunk/doc/tutorial.txt The intention is to give beginners (regarding etree, ElementTree and to a certain extent even XML) an idea about how lxml.etree works and what features can help them in getting their problems solved. I happily borrowed ideas from Fredrik's ET tutorial. Still, there's lots of stuff missing, so if someone feels ambitious and finds some time over the week-end, I'd be glad to add another name to the list of authors. :) Everything from fixes and remarks to readily written sections will be very much appreciated. The source for the HTML page is the ReST text file above. Hoping for some helpful hands, Stefan

1 0

[lxml-dev] case-insensitive xpath search
by Paul Eipper 16 May '07

16 May '07

Hello, I wonder if this is the right place to ask, but I am trying to run a case-insensitive search on a XML using lxml XPath. This is the current search (not case-insensitive): keyword = "what to find" o.xpath( '//*[ contains( @*, "%s" ) ]' % keyword ) how could I make that be a case-insensitive search ? thanks, -- Paul Eipper Brasil

2 1

[lxml-dev] find
by Eric Garin 16 May '07

16 May '07

2 1

Re: [lxml-dev] XPath exceptions
by Stefan Behnel 16 May '07

16 May '07

jholg(a)gmx.de wrote: > a quick question on nsmaps in XPath: > Is it intentional that this > >>>> root = etree.fromstring("<root><a>what?</a></root>") >>>> root.xpath("//a", {'':'my/foo/bar/URI'}) > ['what?'] >>>> root.xpath("//a") > ['what?'] > > but > >>>> root = etree.fromstring("<root xmlns='my/foo/bar/URI'><a>what?</a></root>") >>>> root.xpath("//a", {'':'my/foo/bar/URI'}) > [] > > does not? No. Passing an empty prefix should raise the same exception as passing None. Fixed on the trunk. Stefan

1 0

[lxml-dev] Fwd: Re: XPath exceptions
by jholg＠gmx.de 16 May '07

16 May '07

Hi, a quick question on nsmaps in XPath: Is it intentional that this >>> >>> root = etree.fromstring("<root><a>what?</a></root>") >>> root.xpath("//a", {'':'my/foo/bar/URI'}) ['what?'] >>> root.xpath("//a") ['what?'] >>> but >>> root = etree.fromstring("<root xmlns='my/foo/bar/URI'><a>what?</a></root>") >>> root.xpath("//a", {'':'my/foo/bar/URI'}) [] does not? Of course you should do: >>> root.xpath("//foo:a", {'foo':'my/foo/bar/URI'}) ['what?'] >>> Seems like an empty string prefix in an XPath-nsmap does not have the desired effect, basically it is ignored as ns-prefix. I notice that None is explicitly disallowed in an XPath-nsmap argument: >>> root.xpath("//a", {None:'my/foo/bar/URI'}) Traceback (most recent call last): File "<stdin>", line 1, in ? File "etree.pyx", line 1042, in etree._Element.xpath File "xpath.pxi", line 222, in etree.XPathElementEvaluator.__init__ File "xpath.pxi", line 102, in etree._XPathEvaluatorBase.__init__ File "xpath.pxi", line 54, in etree._XPathContext.__init__ File "extensions.pxi", line 73, in etree._BaseContext.__init__ TypeError: empty namespace prefix is not supported in XPath >>> Maybe '' should internally get converted to None and thus raise the same error when used in an xpath nsmap argument dictionary? Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

1 0

Re: [lxml-dev] [objectify] schema type registry: QNames for xsi:type?
by Stefan Behnel 15 May '07

15 May '07

Hi Holger, jholg(a)gmx.de wrote: >> jholg(a)gmx.de wrote: >>>>> Is it easily possible to use QNames in the xsi-type lookup system? >>>> I believe this would be the right thing to do, as lxml should be >>>> consistent. >> I gave it a preliminary implementation on the trunk, could you check if >> this >> works for you? > > With this small fix: > > *** src/lxml/objectify.pyx.ORIG Tue May 15 16:24:31 2007 > --- src/lxml/objectify.pyx Tue May 15 16:23:14 2007 > *************** > *** 1768,1774 **** > name = _xsi > for p, ns in nsmap.items(): > if ns == XML_SCHEMA_NS: > ! _xsi = prefix + ':' + _xsi > break > else: > raise TypeError, "XSD types require the XSD namespace" > --- 1768,1775 ---- > name = _xsi > for p, ns in nsmap.items(): > if ns == XML_SCHEMA_NS: > ! if p: > ! _xsi = p + ':' + _xsi > break > else: > raise TypeError, "XSD types require the XSD namespace" > > > it mostly works for me. Sure, thanks. > However, I detected that the nice nsmap-unification currently does not > handle attributes: > >>>> msg = etree.fromstring("""<msg xmlns:FOOBAR="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>""") >>>> s = DataElement("234837", _xsi="string", nsmap={'myXSD': 'http://www.w3.org/2001/XMLSchema'}) >>>> >>>> print etree.tostring(s, pretty_print=1) > <value xmlns:myXSD="http://www.w3.org/2001/XMLSchema" xmlns:ns0="http://codespeak.net/lxml/objectify/pytype" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance" ns0:pytype="str" ns1:type="myXSD:string">234837</value> >>>> print etree.tostring(msg, pretty_print=1) > <msg xmlns:FOOBAR="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> >>>> msg.s = s >>>> print etree.tostring(msg, pretty_print=1) > <msg xmlns:FOOBAR="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <s xmlns:ns0="http://codespeak.net/lxml/objectify/pytype" ns0:pytype="str" xsi:type="myXSD:string">234837</s> > </msg> > > Now that nsmap-unification has taken place, the myXSD-prefix has not been changed to FOOBAR. > I fear this is not a nice one to fix as all the attribute-value prefixes had to be checked. So basically I think this is not a problem of objectify. Definitely not. While we could potentially look for attributes that we created ourselves, I don't think it is worth having lxml handle this. Users should take care when they use their own prefixes. Maybe worth a remark in the docs... > Not really related to this, I detected what I think is a slight inconsistency regarding nsmap when using None vs '' as nsmap-keys (=prefixes): > >>>> s = DataElement("234837", _xsi="string", nsmap={'': 'http://www.w3.org/2001/XMLSchema'}) >>>> print etree.tostring(s, pretty_print=1) > <value xmlns:="http://www.w3.org/2001/XMLSchema" xmlns:ns0="http://codespeak.net/lxml/objectify/pytype" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance" ns0:pytype="str" ns1:type="string">234837</value> >>>> s = DataElement("234837", _xsi="string", nsmap={None: 'http://www.w3.org/2001/XMLSchema'}) >>>> print etree.tostring(s, pretty_print=1) > <value xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ns0="http://codespeak.net/lxml/objectify/pytype" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance" ns0:pytype="str" ns1:type="string">234837</value> > > Though I'm not sure if this really a bug, a mere inconvenience, or even valid (is xmlns:=... allowed?) Maybe this is rather a user error, but I don't see why lxml should not just convert this to None internally. So, two fixes applied, please check again. :) Stefan

1 0

[lxml-dev] [objectify] schema type registry: QNames for xsi:type?
by jholg＠gmx.de 14 May '07

14 May '07

Hi, I just detected a problem with the xsi-types in objectify type registry in that they are no QNames: >>> schematree = etree.fromstring(""" ... <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> ... ... <xsd:element name="root" type="RootType"/> ... ... <xsd:complexType name="RootType"> ... <xsd:sequence> ... <xsd:element name="s" type="xsd:string"/> ... </xsd:sequence> ... </xsd:complexType> ... </xsd:schema> ... """) >>> schema = etree.XMLSchema(schematree) >>> msg = etree.fromstring("""<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><s xsi:type="xsd:string">2387</s></root>""") >>> print schema.validate(msg) 1 >>> print objectify.dump(msg) root = None [ObjectifiedElement] s = 2387 [IntElement] * xsi:type = 'xsd:string' >>> Note that s is an IntElement wherease it should be a StringElement. This goes away if changing its xsi:type to "string"; however, the doc instance then isn't valid against the schema anymore: >>> msg = etree.fromstring("""<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><s xsi:type="string">2387</s></root>""") >>> print schema.validate(msg) 0 >>> print objectify.dump(msg) root = None [ObjectifiedElement] s = '2387' [StringElement] * xsi:type = 'string' >>> Is it easily possible to use QNames in the xsi-type lookup system? Holger -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

2 3

[lxml-dev] Details of XML Validation errors with lxml
by Eric Garin 14 May '07

14 May '07

2 2

[lxml-dev] XPath exceptions
by Stefan Behnel 13 May '07

13 May '07

Hi all, I've just rewritten the XPath exception generation code to provide better error messages on failure. lxml 1.3 will have two main XPath exceptions that inherit from XPathError: XPathSyntaxError and XPathEvalError. However, the problem is that they are not entirely, well, consistent. When you create an XPath object, you will nicely get an XPathSyntaxError if something goes wrong in the instantiation (parsing) and an XPathEvalError if you call evaluate(). But when you use the other two evaluators (or the xpath() method), parsing and evaluating are really one step, so you will always get an eval error. Meaning, you may get different exceptions from XPath() and the xpath() method for the same XPath expression. It is easy to raise different errors from the xpath() method depending on what libxml2 tells us about the error source. However, libxml2 also uses a generic error code for both syntax and eval errors if the error is not more specific (e.g. for a completely unparsable expression), so there are cases where lxml cannot tell what kind of error it was, so it would have to default to an eval error for the xpath() method. This would still give you different exceptions from the XPath() class and the xpath() method for the same unparsable expression. Another problem is backward compatibility: if we introduce a new exception for the evaluation, these errors will no longer be caught by existing code that catches XPathSyntaxError (or even plain SyntaxError). To make such code run with older versions of lxml, you would have to catch XPathError instead. So, it's easy to do, but you'd have change your code if it uses the original exception. BTW, this fixes the issue of missing namespace prefixes raising a syntax error. You will now get an eval error saying "Undefined namespace prefix". I would like to hear opinions about this before it becomes the official behaviour of lxml 1.3. The trunk currently implements the variant that raises different errors from xpath(). Stefan

1 1

Re: [lxml-dev] relaxNQ errors
by Curtis Scheer 07 May '07

07 May '07

Thanks for the help, so far I am quite impressed with this library. -----Original Message----- From: Stefan Behnel [mailto:stefan_ml@behnel.de] Sent: Monday, May 07, 2007 3:20 PM To: Curtis Scheer Cc: lxml-dev(a)codespeak.net Subject: Re: [lxml-dev] relaxNQ errors Hi, Curtis Scheer wrote: > New to the lxml library so forgive me if I missed this in the > documentation, I am trying to validate an xml file against RelaxNG. The > function relaxing() appears to only returned a 1 or 0 based on whether > it is valid. Is there a way I can get the specific error as to why it > failed? Please refer to the in in-development docs of lxml, they are much easier to read. http://codespeak.net/lxml/dev/validation.html Hope it helps, Stefan _______________________________________________ lxml-dev mailing list lxml-dev(a)codespeak.net http://codespeak.net/mailman/listinfo/lxml-dev

1 0