W3C home > Mailing lists > Public > www-svg@w3.org > November 2003

[SVG1.2] 6 XML Events Integration

From: Jim Ley <jim@jibbering.com>
Date: Sat, 15 Nov 2003 14:54:24 -0000
To: www-svg@w3.org
Message-ID: <bp5eop$iq4$1@sea.gmane.org>

Hi,

I'm concerned on the value of XML Events, SVG 1.2 is a multi-namespace aware
application, it has specific support for DOM 3 events, so we need
multi-namespace events, I do not feel the specification should introduce
spec complexity, implementation cost, and authoring confusion to simply add
a non-namespace aware inferior method of seperating script and content than
DOM 3 provides.

I see two solutions to this:

 Ignore XML events, until there are a Namespace aware version to use.

 Invent an SVG specific extension to add namespace handling to the events.

The first is my clear favourite.  You could also of course carry on and
include the rather useless crippled XML events, but I don't see how valuable
this would be, for the added cost of including.

If it does stay in:

In the following situation:

<handler type="text/ecmascript" ev:event="click">
 <foo:offset xmlns:foo="urn:chicken#" value="10"/>
 alert('a');
</handler>

What is passed to the script engine?

Why is script the inferior brother to Java in the example (an external java
has init called, javascript does not) how is the user agent able to
understand the difference?  I do not believe it is appropriate for a
specification not to be language neutral and

  <handler id="myClickHandler" type="application/java"
           xml:base="http://example.com/myJar.jar"
           xlink:href="#com.example.MyXMLEventHandler"/>
      <param name="offset" value="10"/>
  </handler>

  <handler id="myClickHandler" type="text/ecmascript"
           xml:base="http://example.com/myJar.jar"
           xlink:href="foo.js"/>
      <param name="offset" value="10"/>
  </handler>

Should be identically capable, otherwise porting a Java versioned SVG file
to javascript will be impossible.

Due to these problems, I'd like to see it removed as before.

Jim.

[This I feel strong enough to be an issue if still relevant before last call
phase.]
Received on Saturday, 15 November 2003 09:55:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 23:52:55 GMT