"string" dfn is now ambiguous

[dontcallmedom]

With a recent update to webref, the term "string" has now two possible sources (infra and rdf-concepts), which means bikeshed complains about ambiguous autolinks (e.g. for webnn).

I'm not sure if this is something to fix upstream or through some local curation, but since it's likely to affect many bikeshed specs, I thought I would raise it here.

[tidoust]

I don't know what "upstream" you're thinking about. The rdf12-concept spec and Webref data look good to me. The term "string" in the RDF sense of it is referenced in 6 other RDF specs.

The way such duplicates get addressed in Bikeshed is through (default) linking defaults. For example, that file already tells Bikeshed to replace terms in rdf11-mt and rdf11-concepts with those in dom. A new line should be added to replace terms for rdf12-concepts with those in infra. I'll prepare a PR along these lines.

That approach picks a winner, which isn't necessarily great, but 93 specs currently reference "string" in the infra sense of the term, prioritizing backwards compatibility seems a sane approach.

Ideally, something would alert us when new duplicates start appearing so that we can address them before someone bumps into them. They are now easier to detect when we add a spec to browser-specs, but we don't check dfns on an ongoing basis.

[dontcallmedom]

re upstream - in the past, we've asked spec authors to avoid redefining such generic words (e.g. "uri" IIRC). Note that "string" is a secondary definition of "RDF string" which wouldn't create an ambiguity.

That being said, patching at the bikeshed level SGTM (all the more so as this is a bikeshed-specific issue) - I didn't recall this was possible.

and yes, being alerted could be considered as part of our beloved #789

[tidoust]

re upstream - in the past, we've asked spec authors to avoid redefining such generic words (e.g. "uri" IIRC). Note that "string" is a secondary definition of "RDF string" which wouldn't create an ambiguity.

In object oriented parlance, it would be great to have a "friend" access level. That is, it seems natural for RDF specs to be able to reference "string" without having to say "RDF string". It also seems natural for most other specs to be able to reference "string" in the Infra sense of it.

I note rdf12-concepts also defines "property"... which also means something completely different in RDF and in CSS. I took the same approach. The PR that updates linking defaults in Bikeshed also takes that into account.

The spec also exports other terms that do not create conflicts for now, but are still pretty generic such as "subject", "object", "nodes", "literal"; and terms that could perhaps be flagged as too generic such as "appear".

[tidoust]

@pchampin, see above and below for context :)

All term definitions are in one namespace for Bikeshed. That usually doesn't create problems because most terms are only defined in a single spec, and because most terms defined in multiple specs are used only so often that it's ok to add more context to the cross-reference link to disambiguate.

Things become problematic when specs from different domains define generic terms that have a specific meaning in their respective domain. Here, "string" in the IDL world, defined in the Infra spec, does not mean the exact same thing as "string" in the RDF world, defined in RDF Concepts (these definitions could perhaps be aligned at some point, but that's orthogonal to this issue in any case).

These generic terms are typically referenced by a good chunk of other specifications (93 specs links to Infra, 6 specs to RDF Concepts), so when a new generic term gets defined that introduces a clash, many Bikeshed specs can no longer be generated. Bikeshed now favors CSS2, DOM, Infra over RDF Concepts to fix broken builds. But the consequence is that RDF specs may need to be checked and adjusted to qualify that links to generic terms such as "string" need to target the definition in RDF Concepts, for example by adding a local linking defaults section.

[tidoust]

Well, I believe all RDF specs use ReSpec in practice, and ReSpec requires listing external specs that contain terms of interest, so you shouldn't need to adjust the specs at all. I guess the points are more:

1. Beware when you export new generic terms, that can create issues for others.
2. If you're aware of specs written with Bikeshed in the RDF domain or if people are considering using Bikeshed for an RDF spec, they may need tweaking for links to target the right definition.

[pchampin]

I'm sorry for the mess. But I did anticipate that redefining "string" would cause problems, so I tried to avoid it. The HTML/Respec source code in RDF Concepts is:

<dfn id="dfn-rdf-string" class="export" data-local-lt="string">RDF string</dfn>

Notice the use of data-local-lt which is supposed to avoid exporting the secondary term! Could this be a bug in Respec?

[tidoust]

Oh, I hadn't checked the source. It does look like a bug in Respec indeed, because "string" ends up being copied into a data-lt attribute in the generated HTML:

<dfn id="dfn-rdf-string" class="export" data-local-lt="string"
  data-export="" data-lt="RDF string|string" data-plurals="rdf strings|strings"
  data-dfn-type="dfn">RDF string</dfn>

[tidoust]

I reported the problem in speced/respec#5007.

[tabatkins]

Ugh, that's a silly ReSpec bug. Thanks for reporting, @tidoust.

I'll need to give some thought to how to address this problem more generally; the RDF specs might one day switch to Bikeshed, and I'd like them to work well. We already have similar issues with the epub specs having shared definitions of several common HTML elements, for example.