Editorial: add some more cross linking

[domenic]

Adds cross-linking for "Assert:" and for various reference-related operations and definitions.

[domenic]

Also, what's the process for this kind of additional cross-linking goodness to flow down into all other Ecmarkup-based specs and tools?

[bterlson]

Process is either A) wait for me to update the ecmarkup biblio with the latest (file an issue and I can do it on request) or B) generate your own biblio file from this spec and reference it in downsteam specs/tools.

[bterlson]

I don't think thisValue component and base value component should be dfns. Other specification types or records have identical or similar names (eg. Function Environment Records have a thisValue component). You can use emu-xref to manually link this if you like?

[domenic]

I think it's really important that these be cross-linked, as they're definitely defined terms. (And they're also definitions of terms, so I think dfn is appropriate, although that's not too important.) What is the appropriate way to express such cross-links? In Bikeshed we do <dfn for="Reference" id="...">thisValue component</a> plus <a for="Reference">thisValue component</a> and it generates the correct xref for us. What's the correct way to do it in EMU?

[bterlson]

How are these terms different from any other reference to a field of a record?

[bterlson]

Now realizing there is no good way to do this in emu, fwiw :-P

[domenic]

How are these terms different from any other reference to a field of a record?

They aren't; I'd love to have all record fields linked to their definition too! These particular ones are more confusing than normal to me, so while I was in the area I thought it would be important to clean them up and xref them.

[bterlson]

For now I'd rather be consistent and not dfn field names (especially when one of the dfn'd names exists on multiple record schemas). I also don't think it's super important because the there should be an xref to "Reference" in close proximity (true for the usages I looked at, anyway).

[domenic]

OK, I'll work on removing those dfns, but I think the consistification of how they are referred to is still good.

[bterlson]

Sure I think that part of the change is fine!

[domenic]

The dfns are removed and this is rebased; ready to go.

[bterlson]

Seems good. Dfn's presently don't support an aoid either, but it seems reasonable to add given that not all algorithms will want alg-style steps or emu-eqn-style specifications? Eg. use dfn aoid for prose description of algorithms?

[domenic]

I think dfns do support aoids... when building locally, adding them generates automatic links.

[bterlson]

It's just the normal term-linking semantics (which are slightly different from aoid auto-lining semantics, and may diverge further in the future eg. when I figure out how to support pluralization).

[domenic]

Hmm OK. Well yeah, first-class support for dfn-defined aoids makes sense to me.

[bterlson]

Ok, I'll merge this for now. Can leave the dfn aoids as an aspirational thing ;)