Cart
[Home] [By Thread] [By Date] [Recent Entries]
>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
|
