Add Wiki for Tips&Tricks?

[gimsieke]

This hint probably belongs into the core Saxon-JS documentation, but I was unable to find it there.

I developed a small application with a textarea. I was surprised to see that rendering its content would only give me the placeholder text that I put into the HTML source, rather than the text that was entered by the user. Then I remembered that I had the same issue with a program that I wrote with Saxon CE six (!) years ago. I looked up how I solved it: With @prop:value. Then I read about ixsl:get() that is meant to replace the @prop:* attributes. I figured out that I need to use something like ixsl:get(id('area1',ixsl:page()), 'value').

I suggest that we use the Wiki of this repo in order to document hints like this, ideally pointing to projects where the techniques are being employed. (I’ll add my current tiny project to Github soon.)

[gimsieke]

A versioned HTML page that will be published on https://wendellpiez.github.io/XMLjellysandwich/ is probably better. In order to maintain the Wiki, every contributor needs commit rights to this repo. Patches to the HTML page, on the other hand, can be filed as pull requests by anyone. So maybe I should submit the initial page as a pull request… Maybe later today, unless you get ahead, Wendell.

[gimsieke]

In an own-dogfood-or-vegetables-consuming fashion, we can also maintain the tips&tricks in an XML file and render it dynamically on https://wendellpiez.github.io/XMLjellysandwich/, using Saxon-JS!

[wendellpiez]

@gimsieke I am looking at old tickets ... this is such a good idea, I wish I knew who would use it besides us two. If you think the answer is someone, let's consider taking this up. (My SaxonJS experiments have paused, but I expect them to resume.) There are a number of intriguing models one could contemplate. (On a separate-but-related topic have you had experience processing Markdown in an XSLT context?)

[gimsieke]

I don’t know who else uses XMLjellysandwich, but I have recommended to some people that they use it as a starting point for Saxon-JS projects.

We can create a saxon-js-faq.xml somewhere in this repo, in a bespoke or off-the-shelf vocabulary. Questions/answers can be associated with different categories, such as “Form Elements”, “Javascript”, “Properties/Attributes”, or “Resource Loading”. I think we can use JATS Pumpkin, it has a question element that may contain answers and that allows association with one or more categories using sec-meta/subj-group.

I think we should render the JATS dynamically as HTML. The Q&A list can then be filtered for categories, and maybe we can think of other interactive XSLT operations. Full text search can be performed using XPath since the input won’t be so large that it necessitates an index.

Other people like @namedgraph will probably contribute questions and answers, too.

---

Regarding Markdown rendering, I don’t know of an XSLT that can readily be used.

There are, however, some approaches:

• cx:commonmark Calabash extension step
• an EBNF that can probably be made to work with REx
• commonmark.js seems to run in the browser (not just in nodejs) so you might call it from Saxon-JS

[wendellpiez]

@gimsieke all this sounds great. I have learned a huge amount about git-based dev in the last 24 months so we could perhaps move forward easily with something light-touch. We could do this in a branch, or indeed if there is utility in a live preview online, in the master branch (which Github Pages picks up) -- unless there is a better easier way to configure that (or maybe point a server at a different branch)? In any case since you have design ideas I suggest you proceed whenever so inspired. (Latency is not a problem here.) Once there is something to build from, we could ask for further contributions. I could perhaps scour my stylesheets for any tips or cute ideas. (Hm: maybe the local-save feature in the I Ching demo could be one.)

As for Markdown, really the question is an opener to a longer conversation about Markdown. I have quite a bit to say about that too: for OSCAL we built a kind of cheat "half-parser" to produce XHTML from (a smallish useful subset of) Markdown. However this is not a problem with a single solution and there is also no reason not to demo (every reason to demo) how to wire in commodity parsers such as commonmark.js -- and for that matter, a true EBNF-based parse solution would be great. I suppose now you mention it, today I might try the calling-to-Javascript option simply in hopes of reliability (ha). But perhaps they should all be tried and stress-tested.

One item for our page btw could be a list of links to other SaxonJS demos or applications. As you know such lists are no good (they grow stale) if they are not curated. But we could at least give it a chance and see how much interest there is.

BTW (back to original concept) using the Wiki feature of this repo is also in order if you think it worthwhile. I simply have not had any bandwidth. 😎 But to be honest one of the things I like best about this architecture is the leave-it-and-come-back-later feature.

[gimsieke]

I don’t currently have the bandwidth either, but maybe around Christmas I will.

[wendellpiez]

Sounds good, meanwhile free free to speak up about anything else you find thanks!