On Sunday, 17 March, 2002, 18:27:18, Giles wrote: G> A brief introduction. I'm Alan Hudson, the other lead on the Xj3D G> project, and typically the more politc member :) I'm sure you've all G> meet Justin Couch by now.
Hi, glad to meet you. A similarly brief introduction - I am Chris Lilley, member of the W3C Technical Architecture Group, the XML and Hypertext Coordination Groups, Graphics Activity Lead, and chair of the SVG 1.0 and SVG 2.0 working groups. I have also previously been chair of the CSS WG, member of the HTML, WebFont, and XSL WGs and a co-author of the PNG specification. Before W3C I was at the Computer Graphics Unit at the University of Manchester (for those with long memories of VRML trivia who recall MSDL). G> In regards to W3C, we had a good presentation of SVG and chat with Ivan G> Herman(not Evan Ireland) It was close enough that I could guess, since I was aware that Ivan was going to that event. There has also been contact in the past between Web3D and both Max Froumentin (MathML and XSL WGs, previously from the Computer Graphics lab at the University of Bath) and myself. G> from W3C at our last web3d symposium. His view G> was that the issues that SVG and X3D face are very similar. The G> requirements of rendering a real-time scenegraph are hard and they are G> pushing the XML document model pretty far. I would agree with this assessment. Comparing what a modern SVG implementation does, and what a legacy HTML browser does, is enlightening to say the least. There were many holes and gaps where specs left things unsaid, or assumed a batch transformation model, or had simply never considered interaction, or were focused exclusively on documenting short term existing implementation of legacy browsers rather than looking at a wider architectural model. So for SVG 1.0, where we were expecting de-novo, interoperable implementations right from last call on our spec, there were a lot of challenges. We ended up doing a great deal of liaison work and documenting a bunch of those holes. G> I found myself constantly G> shaking my head in agreement as he described the challenges SVG faced G> and the solutions proposed. I'm definately interested in the ins and G> outs of the SVG DOM specification. We have similar scripting G> requirements which a standard DOM implementation will not handle. The correct solution seems to be to layer the additional methods and objects on top of, rather than as a replacement for, the underlying Core, XML, Events and Views DOMs (and the Stylesheets and CSS OM, though my understanding is that X3D does not use styling). G> That said, I hope that all XML languages will interoperate at some G> level with a standard DOM. Clearly, if by standard you mean the Dom Level 2 stuff. This is generally the ,model that is assumed for the future - a large, single, multi-namespace tree. (For SVG we generalized further to a collection of such trees connected by XLinks to make a DAG, but that is by the by). G> One of the reasons we need our own layer above DOM is for effeciency. G> Passing string representations of field values is unreasonable for some G> of our datatypes. Yes, I know. Its unfortunate that short-term legacy issues have left us with a DOM that is not really object oriented and that is primarily used with a language that is not really object oriented. G> An example would be a coordinate set for a human. G> Its not unusual for X3D programs to animate every vertex each frame for G> an animated human. If we had to represent this data as a string and G> then parse it each frame well, there goes real-time performance. Absolutely. G> So we G> have extra methods which allow you to represent datatypes in there more G> natural form(like float arrays). But, we do allow access to these G> fields with their string counterparts. So we can hand a standard DOM to G> someone and they can access the fields. It may not be the most G> effecient, but it would work. But the point is that you can a) store the stuff in the more efficient array form b) generate the string form on demand and throw it away afterwards c) provide a more efficient DOM object that deals with arrays directly, that is conceptually layered on top of the XML DOM d) give it methods that do sensible matrix manipulations like inversion and multiplication e) suggest that using these methods is more efficient f) provide a feature string so users can test for the availability of these methods and conditionally use them, falling back to the DOM level 2 methods if need be. and the only catch is the XML requirement about preserving all the spaces, line feeds and assorted garbage when you recreate the string, which is a problem. G> Our standard example is someone might use G> this interface to turn on a lightbulb, but not to animate a human. Is G> this the type of reason you needed a layer above the DOM? Yes. G> I've seen references to conformance issues. Are you stating that G> someone cannot build and modify an SVG document via the DOM but G> must use SVG DOM. That has (erroneously) been suggested in this thread, but not by myself or by Batik developers. It is absolutely not the case. Architecturally, it is imperative that access (both read and write) via the XML DOM be supported, and that additional methods and additional rendering layers have defined behavior in face of this manipulation. Which the SVG 1.0 specification does. G> Or is it just faster, more feature rich to use the SVG DOM? The latter. Certainly more feature rich, some information (such as the transitory, animated value of a property) is only available through this DOM. But it very definitely is an addition to, not a replacement for,the DOM 2 features and the Conformance section of the SVG 1.0 specification is very clear about that. -- Chris mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
