[XML-SIG] Is this a bug?
Martijn Faassen
faassen@vet.uu.nl
Tue, 30 Oct 2001 14:20:54 +0100
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