[x3d-public] Don, XSLT protoexpander?

[John Carlson]

There's only one open-source JavaScript Prototype implementation
that i know of, namely X_ITE.

I'll look into it a bit, but Andreas is much better at both X3DOM and
X_ITE, and maybe could layout a design that I could follow that would fit
into X3DOM similar to how the current "JSONExpander" does, nearly a drop in
replacement.

Could we convert Xj3D Prototype libraries to ECMAScript 6?

I'm not really seeing a clean solution in X_ITE prototype expanding that I
have for JSON.   Basically, I do something similar to UNIX pipe, so I can
take toggle the protoexpander on and off like I do in X3DJSONLD, easily
replacing one implementation with another.

I'm the JSON/JavaScript guy, not the XML guy.  Don, you're the XML guy, do
XML-like things. I got very lucky with X3DJSONLD and "JSONExpander" fitting
right into X3DOM from my design.  I didn't even look at how X3DOM was
implemented!  X_ITE is a bit harder to understand.

I'm not really sure how "inconsistent" browsers are these days.

I'm more worried if someone applies the brakes really hard in front of me.

Basically, I'm going to start pushing hard that both X_ITE and X3DOM
conform to ES6 class style development with import/export.  I think it's a
good thing for X3D too.

John

On Thu, May 7, 2020 at 1:18 AM Don Brutzman <brutzman at nps.edu> wrote:

> BLUF: write javascript that uses a ProtoDeclare as a cookie-cutter macro
> design for stomping out new scene subgraphs.  A prototype... expander.
>
> Multiple open-source proto implementations exist.  At first it can be hard
> driving in fog - but it gets a lot easier when you can follow someone
> else's tail lights.
>
> On 5/6/2020 9:53 PM, John Carlson wrote:
> > Can we convert XSLT files to JavaScript?   That's Saxon-JS, right?  I am
> a bit worried about Saxon-CE.  Browser-native XSLT 1.0 processing might be
> feasible? That would be best.
>
> The code patterns in XSLT are verbose (constructing strings and walking
> trees) in ways that don't match how any javascript implementation would go
> about doing things.  I further doubt that they want to include an XSLT
> engine in X3DOM, or depend on inconsistent browser implementations.
>
>
>   Then there would be less code to download?  It would be worth seeing if
> there's a good product for XSLT 2.0 in the browser.
> > What features of XSLT 2.0 are we using in the various stylesheets?
> >
> > We are looking at a total remake for XML/DOM, I think, not sure.  I am
> fairly sure the code deserves re-engineering.
> >
> > Will look.
> >
> > John
> >
> > On Wed, May 6, 2020 at 11:41 PM Don Brutzman <brutzman at nps.edu <mailto:
> brutzman at nps.edu>> wrote:
> >
> >     If X3DOM is written in Javascript then I recommend writing the
> ProtoExpander in Javascript.  Then it will be directly compatible and
> maintainable.
> >
> >     On 5/6/2020 9:32 PM, John Carlson wrote:
> >      > Don, are we on track for an XML/XSLT ProtoExpander for
> integration into X3DOM?  Is it on the wish list?
> >      >
> >      > Thanks,
> >      >
> >      > John
> >
> >     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
> >     X3D graphics, virtual worlds, navy robotics
> 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/20200507/d8af27e4/attachment.html>