[x3d-public] X3DObjectUtil for X3DJSAIL

John Carlson yottzumm at gmail.com
Thu Jun 1 21:04:01 PDT 2017


I cannot compile X3DJSAIL, because Saxon is missing from the classpath.  See:


org/web3d/x3d/jsail/Core/X3DObject.java

import net.sf.saxon.s9api.*;

Also line 745 of CreateX3dSceneAccessInterfaceJava.xslt.

There are other references to Saxon classes.  Perhaps it would be best to catch a generic Exception, or a superclass of SaxonApiException???  I will look into that.  Sounds like a good approach.

This is why I want to separate the Saxon import from the rest of the code, so I can compile without Saxon.
 
I cannot translate Saxon code to JSweet JavaScript…the task is too difficult—I’ve already tried it once.

Please seriously consider my request.

If you can provide a Saxon alternative on the browser client, I would be for that. So far, Saxon-CE doesn’t work.

Moving XSLT/Saxon imports to a subclass, or everything else to a superclass would be desirable.

This is for the TypeScript/JavaScript port.

Thanks,

John

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Thursday, June 1, 2017 11:39 PM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: X3DObjectUtil for X3DJSAIL

The x3djsail.classes.jar only has X3DJSAIL classes and stylesheets, not Saxon... in fact, not finding Saxon in the full.jar either

	http://www.web3d.org/specifications/java/X3DJSAIL.html#Downloads
	

	X3DJSAIL.3.3.classes.jar (~8MB)
	http://www.web3d.org/specifications/java/jars/X3DJSAIL.3.3.classes.jar

	X3DJSAIL.3.3.full.jar source, documentation, etc. (~24MB)
	http://www.web3d.org/specifications/java/jars/X3DJSAIL.3.3.full.jar

If you try to invoke Saxon without classpath, you get some sort of "class not found" exception.

We could make the code a bit smarter to give an informed exception "Saxon not available, cannot apply XSLT stylesheet transformation" instead, acting more gracefully.

Anyway that is fine tuning.  You should be good to go without saxon already.

p.s. G'day mate!  8)


On 5/31/2017 4:26 PM, John Carlson wrote:
> 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.
> 
> Thanks!
> 
> John
> 
> John
> 
> On May 29, 2017 11:41 AM, "John Carlson" <yottzumm at gmail.com <mailto: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.
> 
>     John
> 
>     On May 29, 2017 1:39 AM, "Don Brutzman" <brutzman at nps.edu <mailto: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.
> 
>         http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/ConfigurationProperties.html <http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/ConfigurationProperties.html>
> 
>                  "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
> 
>         http://www.web3d.org/specifications/java/X3DJSAIL.html#SpecificationChanges <http://www.web3d.org/specifications/java/X3DJSAIL.html#SpecificationChanges>
> 
>         http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt <http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt>
> 
>             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.
> 
>         http://www.web3d.org/projects/wish-list <http://www.web3d.org/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
> 
>         http://www.web3d.org/specifications/java/X3DJSAIL.html#TODO <http://www.web3d.org/specifications/java/X3DJSAIL.html#TODO>
> 
>         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 <mailto:brutzman at nps.edu>
>         Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 <tel:%2B1.831.656.2149>
>         X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
> 


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   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170602/83a948ea/attachment-0001.html>


More information about the x3d-public mailing list