[XML-SIG] Re: xmlproc, SAX and EntityResolver

[uche.ogbuji@fourthought.com]

> 
> * uche ogbuji
> | 
> | [reporting of external DTD subset and external parameter entities]
> |
> | This no longer appears to work in xml-0.5.  Unfortunately, my
> | current code it pretty complex, and I first of all want to make sure
> | this wasn't an intentional change.  I'm pretty sure I've narrowed it
> | to xmlproc, but if I'm told this should _not_ be so, I'll work on a
> | stripped-down test-case.
> 
> As I recall, you fixed the reporting of the external DTD subset in
> xmlproc (the version in xml-0.5). However, you didn't do it correctly,
> so in my development code I have the correct patch (which is not
> released yet).

Oh yeah.  I actually fixed this for xml-0.4, but it was so long ago that I 
forgot.  I recently discovered that I had the wrong sym-link, and I've been 
using xml-0.4 instead of xml-0.5, even after installing the latter.  So when I 
fixed the link and started using xml-0.5, my patch to report the external DTD 
subset wasn't there.  Duh!

You'd mentioned before that this patch of mine was "wrong", but I didn' know 
how to do it the "right" way, so thanks for the code snippet below.

> Adding this to drv_xmlproc.py should do the trick for the external
> subset:
> 
>     def resolve_doctype_pubid(self,pubid,sysid):
>         return self.ent_handler.resolveEntity(pubid,sysid)

Unfortunately, on preliminary testing it doesn't appear to work.  I'll work on 
an isolated test case and get back to you.

> This will not affect external parameter entities. If you need those as
> well, let me know. They will be reported by 0.60, but that may still
> be a couple of weeks into the future.

It looks as if 0.60 will be very helpful to me when it's released.

> A worse problem is that, as Paul pointed out, Python SAX
> EntityResolvers return the system identifier of the entity rather than
> an object from which the entity contents can be read. I intend to fix
> this when we release SAX 2.0 unless someone screams loudly.

For my selfish purposes (constructing DOM trees from SAX events), this doesn't 
affect me, so it's okay with me to wait until SAX 2.0.

The only thing I'd mention is that discussion of SAX 2.0 on XML-DEV appears to 
be going at a pretty deliberate pace (a good thing!), and so 2.0 might be a 
ways off.

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org