[XML-SIG] Re: [DO-SIG] Python language bidning January 2000 Draft

Martin v. Loewis martin@loewis.home.cs.tu-berlin.de
Mon, 26 Jun 2000 23:06:22 +0200

> I'm doing alot of work with XML these days and with the
> XML Document Object Model (DOM), in particular.  Now, 
> these DOM standard, http://www.w3.org/DOM/, is specified
> as an IDL interface.  Further, key parts of this interface
> use attributes. :( Waaaaaa.  
> The end result is that an important Python and Zope interface, 
> DOM, is substantially affected by the choice of a language mapping
> for CORBA IDL attributes! This is ironic since many (most) 
> applications of DOM in Python will have nothing to do with

I fully appreciate the problem; there are a number of ways viewing it
that make it look better:

1. While W3C uses OMG IDL to express the DOM, they explicitly don't
   use the OMG language mappings, as they may appear simpler without
   CORBA. For example, in the C++ mapping, you'd need to care about
   CORBA memory management and _narrow calls - which you can ignore,
   to a degree, if you know a local implementation.

   So the DOM IDL is merely meant as a guideline for defining the API,
   without prescribing the API for all languages. It would be
   perfectly ok if the is the DOM mapping to Python, and if this is
   different from the CORBA IDL mapping. It would be even "allowed" if
   each implementation was using its own mapping - since the API to
   the parser is non-standard (*), applications have to pick a
   specific parser, anyway.

   However, I'd agree that having consistent mappings is desirable.

2. The CORBA IDL language mapping only specifies the minimal available
   API; implementations are certainly free to provide extensions. For
   example, DOM implementations could readily offer mapping IDL
   attributes to Python attributes. They would still be
   mapping-compliant if the offered the accessor methods *in
   addition*. It would then be user's choice to pick one of these


(*) OMG currently considers the XML/valuetypes RFP, which aims at
defining IDL values (as opposed to interfaces) for representing XML
documents in a structured way. The current proposal is to use CORBA
2.3 valuetypes in a DOM-like API; they also define an API to a DOM
parser. With that, there would be a standard way for CORBA
applications to get a DOM tree given a linear XML document.