Supporting definition aliases

[beverloo]

As of now, defining a concept of "webapp" can be done using:
<dfn>webapp</dfn>

This enables us to use <a>webapp</a> when referring to it. However, when having to use the plural form, an explicit title attribute is needed on the anchor: <a title="webapp">webapps</a>.

An alternative would be to accept aliases for a definition, or, if we want to keep it limited, only an explicit plural. For example:

<dfn data-aliases="webapps appz">webapp</dfn>
<dfn data-plural="webapps">webapp</dfn>

It would remove some of the useless churn.

+@mvano

[mvano]

Agreed, defining the alias once per definition instead of every time the alias is used would be a lot more elegant.

[darobin]

This has been discussed on spec-prod. It's a welcome feature, but the idea is to use the same syntax as Bikeshed.

[halindrome]

To be clear, the bikeshed syntax is something like:

<dfn title="synonym|other synonym|plural of synonym">the actual term</dfn>

Which seems pretty reasonable.

Here's a link to their documentation: https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md

[halindrome]

I have started working on an implementation for this. However, I am concerned about the way bikeshed does 'namespacing' of definitions. I like the idea, but using arbitrary boolean attributes to do it seems like it could easily collide with real attributes. Also, it means that there can only ever be a pre-defined collection of definition 'types'. (I note that someone indicated you can use data-dfn-type to declare the type of an attribute, but that is not documented as far as I can tell.)

Obviously for most of us this is irrelevant. But if I want to have multiple collections of definitions in a document or family of documents (e.g., the ARIA specs have attributes, states, and properties - these could be in separate spaces to avoid collisions) then there should be a way of declaring an arbitrarily named 'namespace'.

I will kick this around on spec-prod to see if I can get some consensus. Right now I am going to just not implement definition types.

[darobin]

I don't think that those are problems. I don't think those attributes will ever really conflict, and obviously the processor should remove them. I don't think it makes the set predefined, it just restricts the set to those that are supported by the implementation (a set that can be extended, but only through the sanity of code). That strikes me as a good idea.

I don't think that we should have namespaces for collections of documents. These things should either be completely global or completely local to the document (which Bikeshed supports). Adding levels in between is, IMHO, weird. If the definition is reusable in a "family" it ought to be reusable everywhere.

[halindrome]

Hmm. I agree that there are global 'namespaces' that it makes sense to share. I just envision collections of documents (like the ARIA 1.1 specs - there are 4 or 6 of them in development) that will need to disambiguate between various classes of terms easily. But I suppose in that case the disambiguation is relevant for any external document that might want to reference the terms too. Okay - I think I agree.

But I still hate introducing random attributes into elements, even if they get removed. It's icky. And I know there will be a collision. I can feel it.

[halindrome]

On a related note, in Bikeshed the default 'namespace' for definitions is 'dfn', and those are by default not exported. It's a fine design choice, but it does mean that anyone who wants their existing definitions exported into the magic shared space is going to need to edit their ReSpec source in order to move the things they want external into a different space.

[halindrome]

Bikeshed has some syntax that I am not certain we can easily support:

There are several additional shortcuts for writing an autolink:

• 'foo' (apostophes/straight quotes) is an autolink to a property or descriptor named "foo"
• ''foo'' (double apostrophes) is an autolink to any of the CSS definition types except property and descriptor
• <> is an autolink to a type/production named ""
• <<'foo'>> is an autolink to the the property or descriptor named "foo" (used in grammars, where you need for non-terminals)
• <<foo()>> is an autolink to the function named "foo" (same)
• <@foo> is an autolink to the at-rule named "@foo" (same)
• {{foo}} is an autolink to one of the IDL types for the term "foo".
• [[foo]] is an autolink to a bibliography entry named "foo", and auto-generates an informative reference in the biblio section. Add a leading exclamation point to the value, like [[!foo]] for a normative reference.
• [[#foo]] is an autolink to a heading in the same document with the given ID. (See Section Links for more detail.)

Some of these seem ambiguous to me. Others, with <, will not be available in ReSpec because of HTML parsing. the {{ is easy. the [[# is a great idea and we should do it, but it is a different part of our parsing from dfn linking.

Anyway, thoughts?

[halindrome]

I am planning to do a pull request that supports the basics of this soon - aliases and 'namespaces'. We can look at the broader support for more of the bikeshed - like features in time.

[marcoscaceres]

closed via #455