The DOM: the realist and the implementer

[Didier PH Martin]

Hi Ray,

Ray said:
What do you feel is needed beyond the current W3C DOM standard methods for
querying the
levels and modules of support in a DOM implementation?

Didier reply:
Simple. An interface (even defined in OMG IDL) that allows clients to query
the provider DOM level support.

Ray said:
COM/DCOM is already anticipated to divide into separate interfaces for
expansion, because
that is how that object model handles expansion.  Different models/bindings
have the
freedom to expand in the way most suitable to the binding.  Don't expect
every other
language to follow suite, for example in Javascript where expansion is
simply done
directly to the object -- even if it is just COM objects supplying the
implementation
because an IDispatch approach is taken to supply a non-segmented interface
if I
understand it correctly.

Didier reply:
It seems that you missed something Ray. I'll be more explicit and just do
this simple experiment Ray.

a) use, as you said, the actual DOM IDL interface definition as a template
and create a C++ interface with virtual members. This is only if your
compiler creates a structure containing pointers to functions. Right there,
it means that you choused a specific binary signature for your component. If
you publish this binary signature convention, an other component that wants
to interface with your component will have to be able to use this binary
signature. So, right there you have to choose for a practical interface - a
binary signature - for your component.
b) obviously your components would have to be packaged as a shared library
on certain platforms and as DLL on others
c) Now that you made all these choice. Play the following game:

1) create a client component with an interface that added new members. To be
practical, let's say that the original interface was:

class test
{
	void virtual member1() = 0;
	void virtual member2() = 0;
}

Remember that you made the choice that your binary signature is a struct
containing pointers to functions (an arbitrary one, you may choose an other
kind of binary signature). If you are lucky enough that you compiler creates
that with the above construct then we are OK. Otherwise, you may have to
implement it yourself with a C struct. if lucky enough with your class,
derive from it and just make an implementation of each member having a dummy
content like printing or displaying the member name.

2) now, that you have created a component providing a service, let' now
create a client having this interface:

class client
{
	void virtual member1() = 0;
	void virtual member2() = 0;
	void virtual member3() = 0;
}
Question: will this client component work with the provider we created?
Obviously no.

---> Here is what I mean with the notion of contract.

Conclusion:
If we say that the DOM has to be available in any kind of languages.
Actually, the weakness is that the IDL specification chosen was created for
remote invocation not for in-process usage. Right there, the is an impedance
mismatch between the definition and the usage (except if you want to access
a DOM provider at the other end of the globe). So, the usage of an OMG IDL
is not necessarily judicious and may have been justified by politicial
pressure ( I can understand that, after all W3C is a consortium of vendor,
not a representant of users needs). Nonetheless, most of DOM usages are
intra-adress space usage. Thus, the missing parts are:

a) defining the interfaces with at least an IDL and set of specification
that defined a particular binary signature so that components can _really_
talk together within the same address space. I do not say here that the
interfaces should not be defined with the OMG IDL. Someone may have the need
to ask for a DOM service at the other end of the globe :-)). Or to compile
and convert the document in a DOM in an address space and use it in an
other.
b) Defining at least one interface that allows the client to probe the DOM
provider. This interface is a fixed contract and do not change. This way,
the client can query the DOM version throught a permanent interface that do
not vary in time. Then, the client can, from the information received with
that interface use the provider or not. Practically speaking, the client may
understand only DOM 1, the provider may only support DOM 2, then the client
cannot inter-operate with the provider. case 2: the client only understand
DOM1, the provider supports both set of interfaces, the user may obtain the
right interface set from the provider. Even if each interface do not have a
query interface mechanism, the provider may provide the right set of
interfaces.


Note about the query interface on each node:
you know that the DOM is, in some ways, an implementation of the composite
pattern (gamma & al. 1995). Let's say that you have a root interface used to
query the DOM version and obtain the root node. if the elements of the DOM
where designed to support a query interface mechanism, then the root
interface may, in this case, return a node interface. Now let's say that the
DOM is an ever evolving entity and that in year 2020 the root node is not
anymore the "document" node. Then, in this case, if the returned node is
simply a "node" and that a query interface mechanism is provided, then I can
query the "node" for the kind of interface desired, in 2020 that may
probably by a "library" interface :-) Actually, within the current interface
definitions I can't. I have to request for a "document" node, if this
evolves into a library object, then its over, the contract is not respected
any more. The best solution is to provide to the client a "node" object and
then from this object obtain either a "document" or a "library" interface.
This time the contract works. But, let's be indulgent and say that if at
least a non changing interface is provided then a query interface on each
interface is not necessary, the client will know that DOM level-124 (in year
2020) starts with a "library" interface not a "document" interface. So, in
that case, the non-changing interface should return a typeless
interface...hummmm, is that against the OMG interface principles. There we
go, maybe here, a potential Y3K bug in view :-)))

We can also say that the interfaces are simply templates, that the IDL was
used only to please the OMG consortium and that in fact, the IDL is a fad
not to be used in real life. OK, if the recommendation say that I should not
take the IDL for an implementation but only as an inspiration, this is at
least clear that I should not use the IDL for a DOM implementation. Also, if
implicitely it is said that I can do whatever I want with the interfaces,
add or suppress members, then why do we have recommendations then?

I hope that now you see the incongruity of the situation.

Anyway, my proposal is not to judge the DOM WG which had to deal with enough
political pressure from its members. But to help us create truly
inter-operable components by providing enough information to implementers so
that at least, they know what the contract is and how to fulfill it. And
most of all, to provide to users components that are inter-operable, at
least, within the same middleware convention. This is not even the case
today with the actual DOM recommendations.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind at netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.