[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Place under sun
- From: Philippe Le Hegaret <firstname.lastname@example.org>
- To: Alexey Gokhberg <email@example.com>
- Date: Thu, 18 Jan 2001 16:08:38 -0500
[replying from the web archive. sorry if the mail headers are
Alexey Gokhberg <firstname.lastname@example.org> wrote:
> FACT 2:
> "Document Object Model (DOM) Level 2 Core Specification Version 1.0. W3C
> Recommendation 13 November 2000" (http://www.w3.org/TR/DOM-Level-2-Core)
> specifies the collection of abstract DOM interfaces, as well as bindings
> for few languages.
> Bindings for the following languages are specified:
> * Java
> * ECMAScript
> Therefore, the only general purpose programming language supported by
> this specification is privately owned (and, strictly speaking,
> non-standard) Java.
That's right but you're the first person that I know to really complain about
that fact since 1997. The DOM interfaces are defined using the OMG IDL and
we're providing the two major relevants programming languages for the Web in
the specifications. We asked and had several questions/requests to include more
languages but we never really got any result on that. The more recent thread
was in the DOM public mailing list . As you will be able to read, Mike
didn't find a strong support for a DOM C binding.
One other reason why we keep the Java/ECMAScript bindings is to garantee
interoperability between implementations. Since they are part of the
recommendations, they're normative.
> Plenty of other languages, recognized by international standard authorities
> (and widely used by the world community), like Ada, C, C++, Cobol, etc., are
> not supported.
Yes and the DOM is implemented in a lot of languages. The primary concern
should be the interoperability. Is there an advantage to standardize the ADA
bindings for the world community? Are you aware of more than one implementation
in this language and, if yes, is there a real desire to have interoperability
from the parties?
One other point: the DOM WG recently changed his rules for the DOM
specifications and especially the move from Candidate Recommendation to Proposed
Recommendation (we're still working on it). It has indirect impacts on the
bindings embedded in the DOM specs. Adding a new binding requires some works
and we don't have enough resources to handle all of them. So if there is some
interests/resources from the world community to standardize a binding, I
encourage them to send a proposal in the DOM public mailing list. Keep in mind
that a simple transformation from the XML or from the OMG IDL is not enough.
> Several times the "lack of resources" in W3C was mentioned on this thread. A
> little bit surprising, given that "... Most companies in the XML/Web industry
> have an interest in public, vendor-independent, interoperable Web-based
> technologies, and virtually all join the W3C in hopes of furthering their
No, this is not a surprise. Not all compagnies who have interest in the DOM
have enough time and resources for the DOM WG. The W3C has also limited resources
for the DOM.
> CONCLUSION: The (public) DOM specification promotes (privately-owned)
> Java programming language.
The DOM WG opinion is different: we're using a pragmatic approach and by
providing the Java bindings in the DOM recommendations, we are enforcing the
interoperability of Java implementations.
> And quite opposite, various vendors providing C++ implementation of DOM will
> likely implement very different C++ interfaces for the same IDL, and there
> would not be possible to write an application in C++ which is not dependent
> on any particular C++ library implementing DOM.
> On the other hand, few biggest companies participating in W3C have very solid
> experience in C++.
Yes, various vendors are providing C++ implementation and some of them are
members of the DOM WG but they never had enough interest to standardize them.
Why don't you ask the compagnies (or the world community) why they don't request
a DOM C++ binding?
> By the way, I think that the present specification for ECMAScript
> binding in DOM Level 2
> (http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html) is
> still very unprecise. Consider, for example, the following passage:
> "... The Node class has the following constants ..."
> It is Java having "classes" and "constants", not ECMAScript.
We spent some emails on this subject. The goal was to expose the constants
in the appendix. ECMAScript does support some notions of class. Finally, we
came up with this current wording and nobody else complained. Note that
we're also using the term "Prototype Object". A more accurate quote would have
Prototype Object Node
The Node class has the following constants:
-- ECMAScript Language Binding
Thu, 09 Nov 2000 23:12:46 GMT
> I leave alone the specification of ECMAScript binding in DOM Level 1
> which is a true nightmare. I can hardly beleive that authors of this
> specification had ever seen ECMA-262 text. (What about the "unsigned
> long" data type in ECMAScript ?)
This problem has been reported and fixed in the DOM Level 2 REC.
We had some others problems with the OMG IDL and they have been fixed too .
> As the result, I had to write my own (unperfect, I know) specification
> for DOM binding when I implemented DOM support for my ECMAScript
> interpreter. It was a hard job, wich I could avoid if there were an
> acceptable specification from W3C ...
And why didn't you submit your ECMAScript binding to the DOM WG? Since you read
the ECMAScript appendix, please read also the status in the DOM
specifications. There is a link on how to submit comments to the DOM WG.
We recently published some errata to the DOM Level 2 specifications and some
of them are based on public comments . Unfortunately, don't expect a quick
reply from us, it takes time to process and make decisions.
Philippe Le Hegaret - http://www.w3.org/People/LeHegaret/
World Wide Web Consortium (W3C), DOM Activity Lead