[XML-SIG] Ugh! Why are DOM access methods spelled with a leading '_'?

[Duncan Grisby]

On Tuesday 27 June, Uche Ogbuji wrote:

> We used our own version of the DOM IDL, with a few mods.  Fnorb was
> easy, but for ILU we had to make liberal use of underscores to
> escape clashing names, although as Martin von Lowis has pointed out,
> most of the errors are for CORBA 2.3 only and were not errors for
> CORBA 2.2.  Besides changing the few clashing names, the DOM IDL in
> general compiled just fine.  I think people have been making far too
> much of the few errors name-clashes Duncan Grisby turned up.  Note
> that Duncan Grisby maintains the unsurpassed omniORBpy, by far the
> most compliant 2.3 ORB for Python.  It is far stricter than
> Fnorb/ILU, but only emerged after we took CORBA out of the 4DOM core
> (and, IIRC, after our earlier discussion on Python/DOM binding).

I'm sorry I introduced the stuff about the name clashes. I just meant
it to be evidence that aiming for compliance with the Python CORBA
mapping was more trouble than it's worth. As Martin pointed out, all
but one of the clashes are trivial to fix, anyway [1]. The only issue
is really with the W3C since they claim their IDL is CORBA 2.3.1
compliant, which it plainly isn't.

I don't think people who are using/implementing DOM should religiously
stick to the CORBA mapping. As long as you keep to the intent of the
IDL, it will be trivial to map whatever you use into the full CORBA
mapping. This could even be done at the IDL compiler level, so there
wouldn't need to be any proxy objects doing the translation.

As an example, dom::Attr is defined as:

module dom {
  interface Attr : Node {
    readonly attribute DOMString        name;
    readonly attribute boolean          specified;
             attribute DOMString        value;
                                        // raises(DOMException) on setting
    // Introduced in DOM Level 2:
    readonly attribute Element          ownerElement;
  };
};

omniORBpy currently maps that to the following (sort of -- I've cut
out a few things which aren't relevant, and wrapped some long lines):

# Attr object reference
class _objref_Attr (_0_dom._objref_Node):
    def __init__(self):
        _0_dom._objref_Node.__init__(self)

    def _get_name(self, *args):
        return _omnipy.invoke(self, "_get_name",
                              _0_dom.Attr._d__get_name, args)

    def _get_specified(self, *args):
        return _omnipy.invoke(self, "_get_specified",
                              _0_dom.Attr._d__get_specified, args)

    def _get_value(self, *args):
        return _omnipy.invoke(self, "_get_value",
                              _0_dom.Attr._d__get_value, args)

    def _set_value(self, *args):
        return _omnipy.invoke(self, "_set_value",
                              _0_dom.Attr._d__set_value, args)

    def _get_ownerElement(self, *args):
        return _omnipy.invoke(self, "_get_ownerElement",
                              _0_dom.Attr._d__get_ownerElement, args)


It would be very easy to add a flag to the IDL compiler which
generated the obvious __getattr__ and __setattr__ methods. The server
side would still have to use the _get and _set methods.

Cheers,

Duncan.


[1] The only clash which can't be fixed by escaping the IDL
    identifiers with an underscore is the interface named "Range" in
    module "range". This is really a problem for the W3C to fix, but
    it would be easy enough to relax the name scoping rules to allow
    range::Range to pass the IDL compiler.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --