Chris Lilley wrote: >On Sunday, 17 March, 2002, 18:27:18, Giles wrote: > >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). > We have not done that yet. Mostly a matter of time. Justin has started a proposal for how this would work. Don Brutzman has been preparing for this as well. We are hampered a bit by the fact that we have an encoding that is not XML based. So we are trying to please two different groups. Style Sheets are definately not in the original VRML specification. The problem becomes either specifying an analagous VRML syntax for each feature, or just having features in the XML encoding. From an abstract specification viewpoint I dislike doing that. Especially when we are trying to sync so many architectural/encoding users. We have to keep a common view between scripting access(DOM and non-DOM access like Java bindings), XML and non-XML file formats(original UTF8 and stream binary). So we will support style sheets but its been a hard road getting there.
> >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). > yes, Dom level 2 or maybe 3 in the near future. The multi-namespace tree environment is the one we are really trying to validate right now. I really want to integrate with at least one if not multiple XML spaces before we ship our standard. I think SVG is the right one to bite off first. We have a pretty common vocabulary and adding a nice 2D rendering engine to 3D simulations is a commond request of our users(either as a layer above the 3D space or as an internal texture to an object). > >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. > This brings me back to the questions Justin was having. We had hoped we could parse a multi-namespace document and just pass the SVG elements onto an SVG renderer. I'm guessing what we are facing is the difference between future desires and current functionality. Right now it seems very heavyweight for us to use Batik to render SVG content. I have not dug into the actual Batik codebase yet, so I'm only going by Justin's report of the interfaces. What I really want to avoid is having several copies of the parsed document around in memory. Hence why we wanted to hand Batik a stock standard DOM and have it render the content. We already have alot of our own URL resolution and caching architecture, so we'd like to avoid having Batik do these functions as well. Same would go from the other side, ie an SVG document utilizing X3D to render some 3D. You should be able to hand us a document fragment and expect us to render that, without having to use our custom DOM layer. An ideally we would only use the resources like caches and threads that are absolutely necessary. In the static case, ie you ask use to render a scene once, then we should just render the scene and release all resources. My hope is that Siggraph this year, which is July 21-26, we can show a demo which includes both X3D and SVG content running together. Likely this would require a fair bit of coordination between our groups. One question would be whether anyone in this group is planning to attend Siggraph? Another would be whether this timeframe would work from a timing perspective of the batik team. Ie, if we agreed to help program some of the changes we think are needed in Batik(of course we could be wrong that they are needed), would this be a good time? We've been releasing major releases of Xj3D about every 4 months and plan the next one for Siggraph. Obviously I'm not familiar with the current timing of Batik releases nor when you might be able to release another version. But as a general question for this group, does this fit into your concepts for where Batik is going? -- Alan Hudson President: Yumetech, Inc. http://www.yumetech.com/ Web3D Open Source Chair http://www.web3d.org/TaskGroups/source/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
