RE: DOM 2 and .NET

[Joshua Allen <joshuaa@microsoft.com>]

>I've noticed that MS is claiming DOM 2 compliancy in their .NET /
System.Xml
>namespace, and yet they reference properties like "documentElement," as
>"DocumentElement," and add properties like "OuterXml" w/ out
referencing
>them as additions to the DOM.  Am I wrong to think that this is an
attempt
>to undermine developers who want to build DOM compliant applications,
but
>don't completely understand the XML specs?

Hi Charlie,

Sorry about the delay in responding.  Hopefully I can shed some light on
this..  First, with regards to the DocumentElement vs. documentElement,
the documentElement property is specified as part of the ECMAScript
binding.  Every language that wants to use DOM has to define a binding
to DOM, and since different programming languages are different, it's
not really possible to define one binding that works for all languages.
Of course, the actual method names remain the same, but things like
upper-case, lower-case, etc. are often language dependent.  It is not a
goal of DOM spec (and would not be a really realistic goal) to have DOM
code from one language be able to be cut-and-pasted and "just work" in
another language.  For example, in the case of C++, your code might look
like:
 objDOM->documentElement, while it would be objDom.documentElement in
JavaScript.  As far as case-sensitivity goes, some languages are not
case-sensitive, so objDOM.DOCUMENTELEMENT and objDOM.documentelement
would refer to the same thing.  Some languages I have used require
*everything* to be upper-case (although I admit I haven't seen any DOM
implementations on these platforms :-))

In the case of the .NET frameworks classes, the capitalization used was
chosen to be consistent with the naming conventions used in the rest of
the classes.  Generally it would probably not be a good idea for
languages to change their bindings to match whichever convention was
used in whichever language happened to have sample bindings defined in
the particular library spec being implemented.  Unless you defined a
universal language to be used in all specs and decided to ignore
languages that require capitalization, etc., then you could end up with
a real mish-mash when people tried to program.  Hopefully people
switching between different languages will not be too confused by having
to use different capitalization conventions.  I think it is more likely
people would be confused by the other thing you pointed out -- the fact
that some methods have been added which may not exist in other DOM
implementations.

In the case of the "extra" stuff, pretty much every DOM implementation
adds some extra stuff to cover things not covered in the spec, such as
loading, saving, XPath, etc.  These particular three have been in MSXML
since the beginning, and are also in Oracle for example.  Adding
features above and beyond a spec seems to be much more acceptable than
implementing a spec only halfway.  At the same time, I can completely
sympathize with the challenges of writing code when you aren't sure
which methods will be portable or not.  Regardless of whether or not
Microsoft even shipped a DOM, this would be an issue.  One strategy is
to just use the spec as your manual, and when you find something that
doesn't work on the platforms you are targeting (because of incomplete
support), you nag the vendor to fully support the spec.  As long as you
use the spec as your manual, you never even know about the various
vendor's proprietary extensions and are never tempted to use them.  For
developers that don't mind using proprietary vendor extensions, there
are plenty of extra things available that they can explore from various
vendors.  Another thing that is useful is for vendors to clearly mark in
the online docs which methods are defined by the spec and which ones are
innovations.  The MSXML SDK has done this in some releases (by marking
non-spec extensions as "proprietary"), and MSDN does this as well in
many cases (by marking to-spec methods as "defined in W3C spec").  I am
hopeful that such a thing will be included in the .NET framework docs,
but can't promise anything considering the way things get when it is
close to ship time.  This practice started in some of the MSDN Web
Workshop areas and MSXML SDKs is something we hope to get better at.

Thanks,
Joshua