Hi,
> The : thing is difficult because HTML UAs are expected to deal with : in
> the tag name and there is content in the wild that depends on this being
> accepted; MS Office produces "HTML" containing tags like <o:p>, for
> example. Since I, and I guess others too, want to use lxml to process
> random content that may have colons in the tag names, hard failure for
> this case is a problem. To make matters worse it is possible that the
> HTML spec will change in the future to introduce some sort of
> namespacing feature which may or may not use colons.
You'd get errors when parsing such stuff with the XML parser:
>>> etree.fromstring("""<o:p>foo</o:p>""")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "etree.pyx", line 2137, in etree.fromstring
File "parser.pxi", line 1301, in etree._parseMemoryDocument
File "parser.pxi", line 1207, in etree._parseDoc
File "parser.pxi", line 782, in etree._BaseParser._parseDoc
File "parser.pxi", line 444, in etree._ParserContext._handleParseResultDoc
File "parser.pxi", line 523, in etree._handleParseResult
File "parser.pxi", line 471, in etree._raiseParseError
etree.XMLSyntaxError: Namespace prefix o on p is not defined, line 1, column 5
but not with the HTML parser:
>>> etree.HTML
<built-in function HTML>
>>> etree.HTML("""<o:p>foo</o:p>""")
<Element html at 2c8030>
>>>
So here's a distinction between HTML and XML, but not API-wise, e.g when creating elements.
For my usecase, I must *rely* on producing valid XML through the API, so making things more liberal potentially breaks my system. That's because I need to pickle (i.e. serialize) tree content and reparse somewhere else. Now if I allow for producing invalid XML, some data receiver will choke on my data.
> Given all of this I would prefer it if it were possible to have an
> HTML-specific mode with much more liberal rules than the XML mode. This
> could then be adapted to support any namespacing features HTML grows in
> the future. For example, if one could do something like
>
> import lxml.html
> lxml.html.Element("o:p")
>
> where lxml.html.Element would be just like lxml.etree.Element but
> without XML-specific validity checks. I guess there might be serious
> practical difficulties with that exact solution, but I think the general
> idea of being able to flag an element as following HTML rules or XML
> rules would be more user-friendly than having a set of rules that
> neither matches the XML nor the HTML model correctly.
Sounds better to me than introducing some mixed set of rules. And I don't even think that it's difficult to implement, though it might mean introducing another public factory or some sort of switch on Element().
Holger
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
