how hard would it be to extend pyRdfa3 to lxml.etree? about pyrdfa3 HOT 2 OPEN

@doriantaylor to be honest, I have no idea. This code is fairly old; when I began its first version (must be way more than 10 years ago…), minidom was in the tool for xml and, following the adage "ain't broken, don't fix it" I never really changed it. I cannot judge the difficulty.

One potential issue may be (but again it may not be…) whether there is a clear compatibility in the interface between the minidom used when parsing a pure XML content (say, an SVG file) and what is produced via the html5parser. I would be surprised if there was a difference, but this must be checked. Obviously, html5parser (which is an external dependency) plays an essential role.

I do not have any objection at all if you try. Mind you, this library is behind the RDFa distiller and parser service at W3C (which has a decent usage), so there has to be extra care in adopting any change…

from pyrdfa3.

It looks like html5lib has an option to construct output with lxml.etree, however my reading of graph_from_DOM is that it's farther down the pipeline than that. One might be able to get away with a small proxy class that does a partial implementation:

• detect lxml.etree._Element
• wrap in something called maybe DOMNodeProxy
• use as normal

I will take a look at what this entails. Maybe somebody has done it already?

from pyrdfa3.