Allowing piecewise Ecmarkup usage in other documents

[domenic]

For a while now I've been maintaining emu-algify, which reaches into the internals of Ecmarkup in order to add ES-style EMD processing and EMU autolinking to https://streams.spec.whatwg.org/.

Right now it's stuck on EMU 2.x, and I thought before I go upgrade it to work with EMU 3.x, I should try to get a public API for myself.

At the highest level, what I want to be able to do is, given as input a HTML document with abstract operation definitions and algorithms, process the EMD syntax within those algorithms, and then get autolinks for all terms and abstract operations defined both in ES and in the document itself.

Here is a more low-level description of how emu-algify currently goes about this:

• Creates a new EmuSpec with the HTML file as input
• Loads the "ES6" bibliography
• Finds all elements matching [aoid], and force-feeds the element's ID and AOID values into the EmuSpec's bibliography
• Runs emu's steps to build emu-alg, to autolink, and to build emu-xrefs, all of which mutate the EmuSpec's document
• Serializes the EmuSpec's document back out.

Currently one big problem I have is that this is over-agressive in autolinking: my table of contents gets autolinked, leading to the strange TOC you see in https://streams.spec.whatwg.org/ where only half the line is linked. (Maybe the fix here is simply to not autolink if already inside an <a> tag...)

Here is perhaps a design that would make sense:

• Create a new public API, call it EmuProcessor, which you can add custom biblios to using a relatively simple public API. Should also be able to add the ES6 biblio, of course.
• Let me feed in EMU strings (including EMD strings) and get out a string result. Or maybe this should be Node -> Node (assuming a jsdom API); that could avoid some re-serialization when in my case I'd probably be manipulating the document anyway for other reasons.

[domenic]

The upgrade to v3.4.0 broke emu-algify because all the internal modules it was reaching into now need to be referenced with require("...").default, and also spec.buildAll was removed :-/. This is to be expected given that I was reaching into private APIs, and I'll pin my version going forward, but it would still be really nice for me if this issue could be worked on.

[bterlson]

I am planning on addressing this (and, in general, the entire bikeshed integration scenario) once I get the latest emd working. I'm expecting there will be some API changes needed possibly including changes to the biblio classes since you'll want to work with it in a first class way (eg. importing symbols from bikeshed).