search

johnlumley / jwiXML

An iXML processor for JavaScript and SaxonJS
MIT License
13 stars 0 forks source link

How to hard wire a grammar #4

Closed wendellpiez closed 1 year ago

wendellpiez commented 1 year ago

This may become evident as I look more closely but so far I see no simple guidance. A pointer would be gratefully received, or tips, or a tdb.

I have a grammar all written: how do I hardwire it into a SaxonJS application?

Presumably I do not need to export the compiler XSLT and have the parser generated fresh at runtime. Can I instead compile my grammar 'all the way' in a build (i.e. when I export my SEF), and have it delivered as a fully-functional library parsing my format, whether as/in/with XSLT/SEF, a Javascript function library (Grammar object definition?) or otherwise?

Thoughts? I am very much liking what I am seeing so far.

johnlumley commented 1 year ago

Wendell,

Currently the jwiXML JavaScript library must be loaded via a script reference on the top-level (X)HTML web page. There is no mechanism (and probably will never be) to get it compiled into the SaxonJS runtime. The dist/jwiXML.processor.xsl file (in the ZIP) adds a few XSLT functions that connect to that library - have a look at it.

To load a fixed grammar, all you should need to do is something like the attached file (XSLT renamed as txt to allow attachment), which is a very minor variation of the sample application. Basically:

  1. Define the grammar as a global xs:string variable.
  2. Define the compiled grammar globally asjwL:compileGrammar($grammar). This will be evaluated once and may be reused many times.
  3. Call jwL:parse($compiled-grammar,$input)to do the parse - the 'tree' member of the map is the XML version of the parse, or error if that is the case.
  4. Compile the overall XSLT with Saxon-EE to produce the SEF in the normal way, which will include the stub API functions (jwiXML.processor.xsl) to connect from the XSLT to the separately loadedjwiXML.adv.cls.js JavaScript library

Hope that helps.

jwiXML.wendel.txt

wendellpiez commented 1 year ago

It does indeed help, quite a bit. This is interesting and I will try it out. Indeed if the function result is cached I'm not sure it would make a meaningful difference in performance to serve up some pre-digested or compiled form. Whether it would make any other meaningful difference (application security?) I will have to ponder.

Thanks!

wendellpiez commented 1 year ago

Actually in its way it's pretty secure, if all I serve is the libraries plus my SEF. Hm!