DOM Level 3 comments

Philippe,

When reviewing WD-DOM-Level-3-Core-20010126, I found a number of
issues that you may want to consider:

Reference to OMGIDL. The latest CORBA revision is 2.4.1,
see http://www.omg.org/technology/documents/formal/corbaiiop.htm
The specific document is formal/2000-11-07, and it is available from
ftp://ftp.omg.org/pub/docs/formal/00-11-07.pdf
(sisyphus seems to be not operational anymore).

Use of enum typedefs. Level 3 uses typedefs like

typedef enum _DocumentOrder {
                      DOCUMENT_ORDER_PRECEDING,
                      DOCUMENT_ORDER_FOLLOWING,
                      DOCUMENT_ORDER_SAME,
                      DOCUMENT_ORDER_UNORDERED
                    };
                 DocumentOrder;

I don't know whether these typedefs are deprecated as anonymous types
in CORBA 2.4.1 (probably they are not), however, I cannot see
rationale for the two names of the type (_DocumentOrder and DocumentOrder).
(In addition, the semicolon is superfluous).

Instead, why not simply write

enum DocumentOrder {
                      DOCUMENT_ORDER_PRECEDING,
                      DOCUMENT_ORDER_FOLLOWING,
                      DOCUMENT_ORDER_SAME,
                      DOCUMENT_ORDER_UNORDERED
                    };

In a CORBA sense, that creates an alias typecode, which is a real
overhead in some applications. The only rationale I can find is that
in C, you'd rather write DocumentOrder instead of "enum
DocumentOrder".

If *that* was the rationale, I think it is pointless: the DOM always
defined specific language mappings, so it could easily say that enums
map to a typedef in C, not to a enum. If you'd execute the strict Java
IDL language mapping, the typedef would be ignored, and an interface
for the enum would be generated.

That brings me to the last remark: enums in interfaces. I think it is
bad style to declare anything but attributes and operations in an
IDL interface. It also causes problems in many languages, e.g. C++ and
Python, you need to get a single "official" copy of the class
corresponding to the interface, which means that all implementations
have to inherit from that class. 

Instead, it would be much better if enumerations would appear on
module scope: that would allow them to be enums on namespace scope in
C++ (and module scope in Python), and it would allow to follow the
official OMG mapping in Java. E.g. for DocumentOrder, you'd get

package org.w3c;
interface DocumentOrder{
  int DOCUMENT_ORDER_PRECEDING = 0;
  ...
}

To me, DocumentOrder.DOCUMENT_ORDER_PRECEDING is much cleaner than
writing Node3.DOCUMENT_ORDER_PRECEDING; it is immaterial whether Node3
is a separate interface or not.

Regards,
Martin

P.S. the naming of the enumerations is another story: in most
languages, they will be scoped with something DOM-specific, so a
conflict is impossible. Following the IDL mapping, in C, you'd get
dom_DOCUMENT_ORDER_PRECEDING (or dom_Node3_DOCUMENT_ORDER_PRECEDING in
the current draft), so prefixing enumerations with their type is
overkill.

P.P.S. I admit that these issues already exist with DOM Level 2,
specifically in the nodeType, but I see no reason to continue past
mistakes.

Received on Sunday, 4 February 2001 18:50:09 UTC