[whatwg] Java language bindings for HTML5

[Kühn Wolfgang]

Hi,

In the future, I see a lot of libraries soft-implementing WebIDL interfaces
without binding against a standard interface, may it be Java, C# or C++.

This is not good for many reasons. The most obvious are that consumers cannot
exchange implementations, and that implementors have no tool support to check
the conformance of their implementation.

A quick search reveals the following implementations for the
HTML5 Canvas Element alone:

Java
	com.googlecode.gwt.graphics2d.client.canvas.HTMLCanvasElement
	com.google.gwt.gears.client.canvas.Canvas
	com.google.gwt.corp.gfx.client.canvas.CanvasElement
	gwt.g2d.client.graphics.canvas.CanvasElement
	gwt.ns.graphics.canvas.client.Canvas

C++
	WebCore.html.HTMLCanvasElement (WebKit)
	dom.nsIDOMHTMLCanvasElement (Firefox)

Other static typed languages
	org.milescript.canvas.HTMLCanvas
	dom.HTMLCanvasElement (esidl)
	com.w3canvas.ascanvas.HTMLCanvasElement
	com.googlecode.flashcanvas.Canvas


Agreeing on a name space does have far reaching consequences, as the example of
	org.w3c.dom.html.HTMLImageElement
in DOM Level 1 shows.

Because of a subtle change in the api the w3c chose to rename the package to
	org.w3c.dom.html2.HTMLImageElement
in DOM Level 2.

However, some 8 years later, the JRE only ships with org.w3c.dom.html,
and the xerces DOM implementation and HTML parser do only support Level 1.

Web-centric use cases for implementing in static typed languages are
* UA implementations such as WebKit or Gecko
* Cross-compiling to JavaScript (for example GWT)
* Automating browsers for testing and debugging

Greetings, Wolfgang

>-----Ursprüngliche Nachricht-----
>Von: Shiki Okasaka [mailto:shiki at google.com] 
>Gesendet: Mittwoch, 19. Mai 2010 05:22
>An: Kühn Wolfgang
>Cc: Anne van Kesteren
>Betreff: Re: [whatwg] Java language bindings for HTML5
>
>Hi Kühn,
>
>I think this is a very good point. Would you mind sending this to
>whatwg at lists.whatwg.org?
>
>I wonder if we apply this rule to HTML5, what will be the likely
>module name for HTML today; html5, html101, or html2010? Any guesses?
>
>The interface versioning is a very important topic for the static
>languages like Java, C++. But I guess this would be mainly the problem
>of the programming language side; since HTML is growing very rapidly
>these days, and browsers often implement draft specifications, we
>cannot simply wait for the drafts become the recommendations. I'm very
>interested in what would be the best way to dealing with that with the
>static languages.
>
>Best,
>
> - Shiki
>
>
>On Tue, May 18, 2010 at 7:25 PM, Kühn Wolfgang 
><wo.kuehn at enbw.com> wrote:
>> Hi,
>>
>> addition is possible. Modification is a problem. For example 
>there was a change
>> in the semantic of HTMLImageElement from DOM Level 1 to Level 2:
>>
>> org.w3c.dom.html.HTMLImageElement
>>        String getHeight()
>>
>> org.w3c.dom.html2.HTMLImageElement
>>        int getHeight()
>>
>> These two definitions are not compatible and must be in 
>different namespaces.
>>
>>
>> Greetings, Wolfgang
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Anne van Kesteren [mailto:annevk at opera.com]
>> Gesendet: Dienstag, 18. Mai 2010 08:28
>> An: Kühn Wolfgang; Shiki Okasaka
>> Cc: whatwg at lists.whatwg.org
>> Betreff: Re: [whatwg] Java language bindings for HTML5
>>
>> On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka 
><shiki at google.com> wrote:
>>> On Mon, May 17, 2010 at 6:27 PM, Kühn Wolfgang 
><wo.kuehn at enbw.com> wrote:
>>>> Hi,
>>>> As for the html5 elements, will there be a new package
>>>> org.w3c.dom.html5?
>>>
>>> This is our concern, too. Historically each W3C specification
>>> introduced its own module name. However, the recent specifications
>>> tend to omit the module specification in the IDL definition.
>>>
>>>     cf.
>>> 
>http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html
>>>
>>> In the IDL files we used above, we chose module names that 
>seem to be
>>> practical, but those are not part of the standard. Hopefully more
>>> people will revisit this issue sometime soon.
>>
>> Can't they all just use org.w3c.dom? We cannot make the 
>interface names
>> overlap anyway.
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>>
>