Collisions with css-syntax's [=invalid=]

[miketaylr]

https://drafts.csswg.org/css-syntax-3/#css-invalid

Would be good to namespace it, I think (or un-export it if it doesn't need to be exported?).

(this broke our build at whatwg/compat#232)

[gkellogg]

Looking to the 1.1 version, the term was exported as invalid.x, perhaps for this reason? It doesn't seem that the term is used in any other RDF (or SPARQL) documents, but could be referenced somewhere.

The term was updated as <dfn class="export">invalid</dfn><span id="dfn-invalid.x"><!-- obsolete term --></span>, but either isn't required at all, or could be changed to class="no-export", which should preserve the (possibly unused) element id. It could also be exported as invalid.x again.

Of course, overlap in terms as general as valid and invalid across an array of specifications is always possible, and xref can be used to limit the space of documents used for automatic resolution.

By "namespace it", I presume you mean to export a term such as "rdf-invalid", as it seems CSS Syntax exports "css-invalid". Looking at webref exported definitions, it seems that there are other specs that export something like "invalid" (selectors and webgpu, for example). Aside from this particular term, which can be made local AFAIK, there are a number of terms that were defined in the 2014 specifications, although not adequately crawled by webref. It would be great to see a policy on this.

[miketaylr]

By "namespace it", I presume you mean to export a term such as "rdf-invalid", as it seems CSS Syntax exports "css-invalid".

In terms of bikeshed, at least, it would mean adding a for attribute on the<dfn>: https://speced.github.io/bikeshed/#dfn-for

[gkellogg]

Respec has data-dfn-for, but that's typically used for defining terms in WebIDL, where the term is part of an IDL interface. I haven't heard of it being used for a spec series, or for terms defined for a spec itself. The Bikeshed docs make it looks like it's intended for pretty much the same thing.

Using data-dfn-for="rdf" doesn't have the desired effect,, anyway. Perhaps because no such WebIDL interface is defined.

<dfn class="no-export lint-ignore" data-dfn-for="rdf">invalid</dfn>

If something like namespacing of terms is contemplated, it should probably be done uniformly throughout the 22 rdf-star specs, and would likely create problems for existing term usage.

[pfps]

What should be done here? It seems strange that there is a problem at all - is there a single namespace for all these things in W3C? Is there a document on what should not be done in definitions (that contains justifications for the prohibitions)?

[gkellogg]

In the case of "invalid", in particular, if it is a term that should be defined by the spec, I don't think there's anything else to do. I did note that it doesn't seem to be used within the spec itself.

In the more general case of clashes in term definitions, I don't think that's an issue, either. There is an "xref" configuration that allows you to set the specific specs from which to look for terms; in the absence of that, it will look at all exported terms. I don't believe there's a policy for this, but other groups may have their own procedures. The namespacing mentioned above is something ReSpec restricts for use with WebIDL, although Bikeshed may have its own rules. If it becomes an issue, @pchampin can raise the issue with staff to determine policy or best practices (@dontcallmedom may have an opinion). In our case, these terms have been around a long time, even though Webref may not have exposed them before. Changing them uniformly would break many inbound links. "Cool URIs don't change"; this includes fragment identifiers.

[pfps]

Valid and invalid are terms defined in the RDF Semantics that have utility outside of the document so they should stay.

I'm going to close this issue without making any changes to the RDF Semantics document.

[dontcallmedom]

could "valid" and "invalid" be namespaced to "entailment" or "inference"? This would mean adding an data-dfn-for="entailment" to the definition (<dfn>), and referring to it via [= entailment/invalid =] in short syntax links. (happy to help with a PR if so)

ReSpec does indeed come with a default namespacing by spec, but Bikeshed doesn't (yet?), and since they're all operating under a shared set of definitions, I think it would be best if we could avoid creating collisions.

@tidoust and I have also superficially explored preventing these collisions to happen unexpectedly; maybe this new instance of the problem will lead us to revise the priority of addressing it.