[XML-SIG] Is this a bug?

[Martijn Faassen]

Fred L. Drake, Jr. wrote:
> 
> Martijn Faassen writes:
>  > namespaceURI of type DOMString, readonly, introduced in DOM Level 2
> ...
>  > I actually appreciate the explictness of namespaces in the DOM, even
>  > though there's a mismatch with usage in XML. It simplifies implementation
> 
>   The catch with this is that the DOM ends up offering no integrity
> assurances internally.  I can see where this would be a pain for some
> applications, but it's really impossible to add this --- more
> applications benefit from the free to make complicated edits and then
> force a check (using normalizeNS() or other methods added in DOM Level
> 3) when the edits are complete.

Right, I agree. That's the 'mismatch' I was talking about; you can't really
check whether a prefix really refers to a declared namespace currently,
etc.
 
>  > a lot, which is badly needed as so many parts of the spec *complicate*
>  > implementation (liveness issues are just one example).
> 
>   Those are a nice can of worms, aren't they?  I know how to address
> them in ParsedXML.DOM, and plan to do so, but no time is currently
> scheduled for that.

I'm willing to live with 'dead' getElementsByTagName eternally; liveness
was a serious design bug in my opinion (for backwards compatibility I
believe, but still).

>  > Zope's ParsedXML has a large DOM unit test suite which can be run against
>  > 4DOM as well. I've recently been advocating getting this test suite out
>  > of ParsedXML and into PyXML instead. This way we can make sure the Python
>  > DOM implementations are up to spec much better.
> 
>   I'll take this as an opportunity to voice my support of any
> initiative to split the ParsedXML DOM tests into a separate package so
> that it may be more easily used without having to grab a ParsedXML
> distribution.  Martijn Pieters put a *lot* of good work into those
> tests, and we pulled a number of clarifications from the W3C to
> achieve it.

Agreed, this is just too good a piece of work to let it idle away hidden
inside ParsedXML.
 
>  > Of course the test suite can contain wrong interpretations of the DOM
>  > spec as well, but a lot of care was taken during the development of it,
>  > and it can be further improved should problems appear.
> 
>   Yet another reason to split it out from ParsedXML, given the
> availability of time to work on that project.

Okay, I'm glad I have your support! So, where should I be sending this
code? :)

Regards,

Martijn