[XML-SIG] XPath and Zope's ParsedXML DOM

[Uche Ogbuji]

> Hi there,
> 
> I've been trying to make XPath work with Zope's DOM implementation,
> ParsedXML. In the process I've discovered some incompatibilities in
> XPath that I had to hack around.
> 
> The problem is as follows. ParsedXML uses DOM nodes that are 
> descendants of ExtensionClass. This means that type(node) != types.InstanceType.
> 
> Conversions.py depends on this in several places, however. After hacking
> around them XPath works better for me.
> 
> Here are the two places where I had to hack:
> 
> The function CoreStringValue has this line:
> 
> result = _strConversions.get(type(object), _strUnknown)(object)
> 
> but, since instances now don't trigger the InstanceType key in 
> _strConversions, this fails and returns None for valid instances. I've hacked 
> around this by doing the following:
> 
> if hasattr(object, 'ownerDocument'):
>     result = _strInstance(object)
> else:
>     result = _strConversions.get(type(object), _strUnknown)(object)
> 
> I'm not sure if this succeeds in all cases and it's a hack. I'll study
> ExtensionClasses to see if there may be a better way.
> 
> The other hack is similar and involves the types.ListType entry in the
> _strConversions dictionary. Again the lookup that takes place in the
> value lambda fails due to ExtensionClass.

Thanks.  Karl Anderson has pointed out all these issues, and they are on the 
docket to fix, but we haven't had a chance yet.

Thanks for the fixes you offer, but you are right that they are problematic in 
the general case.  If you do find features of ExtensionClass that make for a 
better fix, please let us know and we'll give them a try.

Thanks.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management