xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giles <gi...@oz.net>
Subject Re: GVTBuilder error with custom DOMs
Date Sun, 17 Mar 2002 19:08:02 GMT
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message