[XML-SIG] foo.bar vs. foo.get_bar()

[uche.ogbuji@fourthought.com]

> On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote:
> > Yes, but a large part of the DOM REC can't be followed using pure attributes 
> > without __[g/s]etattr__.  I know that one can choose to implement subsets and 
> > approximations to the W3C DOM that don't run into such problems, but that 
> > doesn't suit everyone's needs.  Some of us are looking for full DOM 
> > compliance, and that's why we're dealing with these issues.
> 
> Woah. That's pretty annoying. Can you give an example of such an
> attribute?

After reading your message again, I think I might have fallen a bit shy of 
answering your actual question.  Here's another try.

The W3C spec for Node requires that if the user tries to modify the nodeValue 
interface, one exception must be raised if the node is read-only, and another 
if the new content overflows the platform's string length limits.

But now that I examine the heart of the matter, I guess it's not as bad as I'd 
thought.  We have not been planning to implement readonly nodes in 4DOM, and 
we'd leave string-overflow issues to the Python interpreter, so actually we 
wouldn't need to use __[g/s]etattr__ for Node, and this really brightens 
things.  Node, Element and Text would be hook-free, and another common class, 
Attr, would only need the hook if we insisted on arcane W3C rules with regard 
to specified attributes which don't make much sense without DTD support anyway.

Thanks for making me look into it some more.  Maybe "node.parent" doesn't need 
to be such a hog.  Of course, I haven't looked into how DOM level 2 changes 
things.

-- 
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