Make it easy to add Bikeshed metadata

[domenic]

For the purposes of allowing web specs (written in Bikeshed, or written in something that obeys the Bikeshed definition contract) to more easily reference Ecmarkup specs, it would be good if Ecmarkup could help with annotating ES-style specs correctly. This would allow people to avoid definition blocks that manually and inconsistently import the terms in each spec, e.g.:

• Streams
• Custom Paint
• Web Bluetooth

Here are some easy initial ideas:

• (Blocked on https://github.com/tabatkins/bikeshed/issues/801) Any clause with an aoid should automatically get data-dfn-type="abstract-op" and data-lt="${aoid}".
• Any <dfn> in the source file should automatically get an (empty) data-export attribute, unless it is written as <dfn noexport> in the source file. ES uses <dfn> sparingly and generally only for things that are externally useful.

I am not sure how to handle class/constructor/method definitions. In general other specs don't reference most ES methods, so I think we can leave solving that out for now. But we want some way of markup up all the "sections" (e.g. Promise Objects) as "interfaces" (data-dfn-type="interface", data-lt="${className}"). Maybe we want to mark up the intrinsic constructors as well (so e.g. the Promise constructor gets data-dfn-type="constructor", data-lt="%${className}% (not barename class name, as other specs should always reference the % version!), and data-dfn-for="${className}".

TypedArray classes and constructors are their own problem, where we want multiple terms to go to the same sections. Probably that will need manual markup.

/cc @tabatkins

[tabatkins]

Do these clauses have a <dfn> inside of them, or are they just things with IDs that you want to link to?

[domenic]

They have a <hN> inside them, but not a <dfn>. Arguably the <hN> should contain a <dfn>, semantically speaking, but that'd be a pretty large change...

[domenic]

Also, I should mention, last time I discussed this with @bterlson, he was not a fan of changing the output markup of ES specs so they could be scraped and put into the Shepherd database. Instead he was hoping that Ecmarkup could output some data file directly that Shepherd would consume through a side channel. :-/

[bterlson]

Why :-/? If I can generate a metadata format for you that doesn't require massive amounts of new markup (on a spec that is already many MB in size) that seems like a win for everyone?