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

ECMAScript Binding XML?

From: Gavin Kistner <gavin.kistner@refinery.com>
Date: Mon, 22 Sep 2003 15:11:31 -0600
To: www-svg@w3.org
Message-Id: <56BEF156-ED41-11D7-A85A-0003937E984E@refinery.com>

To help myself (and others) better understand the properties and 
methods available in objects in SVG1.1, I wrote:
(official url should be http://phrogz.net/ObjJob/ but that's down atm)

I got the data into the DB by a couple hours of regexp massaging of:
into a format I could parse and create the SQL commands for.

This source data almost certainly came from a script that already knew 
the internal hierarchy of the SVG ECMA binding. Just like:

Q1) Since this internal information almost certainly exists (possibly 
even directly tied with nice descriptions to every 
object/property/method/argument) is ObjJob pointless? [I think the 
answer is no, since I can't find any similar web interface to the data 
on W3C's site.]

Q2) Assuming that this is still a useful tool (when done)--does anyone 
on this list have access to the real db from which this information 
came? Rather than a (nicely structured) HTML file for it, would it be 
possible to get an XML representation of the above URLs? (And since SVG 
references and inherits from elements like dom::Element and 
events::EventTarget outside the scope, I'd love to be able to get any 
ECMAScript binding for a W3C TR in a machine-readable format.)

Following is the email I sent to the svg-dev mailing list 
'pre-announcing' the tool. Feedback from members here would also be 

Begin forwarded message:

> From: Gavin Kistner <gavin@refinery.com>
> Date: Mon Sep 22, 2003  12:48:19  PM America/Denver
> To: svg-developers@yahoogroups.com
> Subject: [svg-developers] DOM web documentation
> Reply-To: svg-developers@yahoogroups.com
> Summary:
> ========================================
> Go play with the SVG DOM docs at http://phrogz.dnsalias.net/ObjJob/ and
> please give me feedback.
> Note that it's not supposed to be 'done' yet, so be kind :)
> Details:
> ========================================
> Over the weekend I was working on my SVG web app, and wanted to find a
> really clean way to transform mouse coordinates into user space for an
> object.[1]
> In researching the methods and properties exposed by various objects, I
> got really frustrated by the usability of
> http://www.w3.org/TR/SVG11/ecmascript-binding.html
> It's not that it's inaccurate, but it appears to be a straight dump of
> information, not geared towards helping someone understand the object
> hierarchy. Worse yet, due to the multiple inheritance, and the fact
> that child objects only list the properties which apply to them
> individually (instead of the inherited accumulation) it's really hard
> to figure out what can be done for any given object.
> I initially tried to create a visual representation of the hierarchy,
> but gave up after about an hour and the realization that there are many
> objects which inherit from many others. It takes "n-to-n mapping" to a
> whole new level, and the visual representation wasn't going to help
> anyhow.[2]
> So, then I decided that (as I desired for the Photoshop JS DOM) it was
> time to write a web-app to hold everything. Something like MSDN's good
> DHTML reference[3], but with the SVG DOM in it. And supporting object
> inheritance, so that any object will show the properties and methods
> which it has accumulated from its ancestors.
> The result is ObjJob, a web app with the above features, whose DB is
> under MY control :) A couple hours' of massaging the data from the
> official spec and I know have the SVG1.1 specs in there.
> Please test it out and give me feedback -- if it's useful to you as
> it...if it could be useful if only it did _xxx_, or if you would never
> use it.
> In addition to the ToDo items listed on the homepage, I still need to
> bring the properties and methods from the objects outside the SVG
> namespace (like dom::Element and events::EventTarget) into the tool so
> that all those will be properly inherited.
> Footnotes
> ========================================
> [1] My idea is that if I can get the current transformation matrix for
> an object, it should (either directly or with a little manipulation) be
> able to be applied to the mouse clientX and clientY and magically
> figure out where I am on the object. I haven't seen any of the SVG
> experts do this, however. Why wouldn't this be feasible?
> [2] A bunch of objects (e.g. SVGGElement or SVGPolylineElement) all
> inherit directly from SVGElement, SVGExternalResourcesRequired,
> SVGLangSpace, SVGLocatable, SVGStylable, SVGTests, and
> SVGTransformable. I suggest that creating a single non-instantiable
> parent object for these children, which inherited from the above would
> have made the hierarchy far easier to visually portray, understand, and
> hence convey to the end users who need to use such specs.
> [3]
> http://msdn.microsoft.com/workshop/author/dhtml/reference/
> dhtml_reference_entry.asp

Gavin Kistner @ Refinery, Inc.
work: +1.303.444.1777
cell: +1.303.641.1521
Received on Monday, 22 September 2003 17:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:59 UTC