[x3d-public] X3DObjectUtil for X3DJSAIL
yottzumm at gmail.com
Wed May 31 16:26:03 PDT 2017
What we could do is subclass X3DObject and put all XSLT/Saxon related stuff
in there...probably too late now. Sorry I didn't mention it sooner. Or
we could superclass X3DObject and move all non-XSLT/Saxon stuff up.
Basically, I'd like to create a distribution without Saxon.
On May 29, 2017 11:41 AM, "John Carlson" <yottzumm at gmail.com> wrote:
> I am just trying to think what to do before release, and Saxon is a big
> stumbling block for jsweet.
> On May 29, 2017 1:39 AM, "Don Brutzman" <brutzman at nps.edu> wrote:
>> On 5/28/2017 8:02 PM, John Carlson wrote:
>>> I wonder if It would be good to create an X3DObjectUtil.java and put the
>>> conversions in there.
>> There is a utility class called org.web3d.x3d.jsail.ConfigurationProperties
>> that collects a number of capabilities.
>> "Concrete class that enables developers to set custom
>> configuration properties when using X3D Java SAI Library (X3DJSAIL). Output
>> serialization support is provided for indentation, X3D Canonicalization
>> (C14N) and showing default attributes. TODO more to follow!"
>> That way we can deploy X3DObject.java with just the XML output and not
>>> the stylesheet(s).
>> New methods handleArguments and validationReport were put in X3DObject
>> because they would tend to be used there.
>> Will thinking about splitting off a separate utilities class if needed at
>> some point. So far am getting good traction by figuring out when/where
>> functionality is needed and positioning it appropriately.
>> That would make it easier to deploy to a browser, and browsers can offer
>>> alternate implementations of X3DObjectUtil.
>> Not sure there are any impediments or blockers at this point?
>> Not sure how many HTML browsers support Java, and existing X3D players
>> with Java support tend to have their own concrete classes. (Xj3D has three
>> actually, can be pretty confusing.)
>> I've tried to keep X3DJSAIL as consistent as possible with X3D Java SAI,
>> which is pretty old. Suggested changes for future specification work are
>> collected at
>> Let me know what you think. I think it’s a good idea to be able to not
>>> be totally reliant on the stylesheets. Plus we can put other Utils there.
>> Other implementation is always welcome. I'll keep adjusting the
>> stylesheets and checking results.
>> Before working on duplicative functionality, it would be good to work on
>> things that are needed. STL/PLY comes to mind, also X3D Projects Wish List.
>> For your patches, I'd like to keep iterating on representative content
>> problems and adapting/integrating those corrections directly into the
>> X3DJSAIL code autogeneration.
>> Other utilities also welcome in this open-source asset. X3DJSAIL wish
>> list is found at
>> Future libraries will include Efficient XML Interchange (EXI) compression
>> (OpenEXI and EXIficient), XML encryption and signature, X3D
>> Canonicalization (C14N), etc. etc. It would be good to apply jgeom.jar for
>> NURBS too.
>> all the best, Don
>> Don Brutzman Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
>> X3D graphics, virtual worlds, navy robotics
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the x3d-public