Meta: add data-noexport attribute to byte sequence definition

[annevk]

It seems that this specification is getting indexed, but now the definition of byte sequence is clashing with the one from Infra. This causes all kinds of issues downstream.

Also copying @dontcallmedom as he prolly knows about the indexing bit.

[dontcallmedom]

cc @tidoust

[annevk]

Looking at Appendix C I suspect this applies to the other imported definitions there too.

[tidoust]

This was triggered by the recent transition to Ecmarkup, which does not create markup that follows the definitions data model that the specs crawler and cross-references databases rely on. The default rule in the crawler for such specs is to consider that all definitions are exported. I see an issue raised on Ecmarkup to improve support for that model, including adding support for data-noexport, at: tc39/ecmarkup#104

In the meantime, I'll see what I can do in the crawler (or perhaps in Bikeshed which defines a number of link defaults, but then Sourcemap seem to define very generic terms such as column that are probably not meant to be exported in any case)

Definitions in appendix C are not pure definitions in the sense that they are imported from other specs. The crawler should skip such definitions in theory but the logic currently expects the <a> to be wrapped by the <dfn> and the spec has the <a> as the wrapping element. I'll update the logic in the crawler to handle this pattern as well.

[nicolo-ribaudo]

I'm not sure about what we should do here, but I would very happily merge a pull request.

[nicolo-ribaudo]

The crawler should skip such definitions in theory but the logic currently expects the to be wrapped by the and the spec has the as the wrapping element.

We can probably just swap them here? I wrote that HTML manually.

[tidoust]

We can probably just swap them here? I wrote that HTML manually.

That would sure work ;) At the same time, that pattern does not strike me as wrong, it seems a good idea to support it in the crawler.

[takikawa]

I just pushed a commit that should do the dfn & a tag swap and it should be live now, I'm happy to do further adjustments to the markup if needed.

[tidoust]

And I confirm that the swap made the appendix C definitions disappear from Webref. Ideally, some of the remaining definitions should get back to being "not exported", but I'm tempted to leave things as-is for now in the crawler: I'm not sure having them as "exported" is going to trigger any real issue, and some of them were previously exported, so a blanket "make all definitions non exported" rule could create opposite problems (specs not being able to link to definitions in source map).

@annevk, note the updates haven't propagated to Bikeshed yet due to an unrelated bug (see speced/bikeshed#3048).

[annevk]

Thanks all, I believe this is resolved now.

@nicolo-ribaudo @takikawa if you want to use <dfn> for an existing term you can either scope it using data-dfn-for and the like or you can prevent it from exported with <dfn data-noexport>. If you view source on any WHATWG standard you'll find plenty of examples of how this linking contract works.

[nicolo-ribaudo]

Is there somewhere a list of all the terms defined in all specs? It'd be great to be able to lint against conflicts.

[annevk]

There is https://dontcallmedom.github.io/webdex/, but generally conflicts can be okay. Just not when you override something common like "byte sequence" or "UTF-8 encode", which also really only ought to have a singular definition.