@else/url blocking type recognition

[larsgw]

For example, @else/url currently blocks type recognition of other URL-like types added after it is added, and it's added at initialisation. Already existing workarounds:

• disable the type parser of @else/url

Cite.parse.add('@else/url', {dataType: 'String', parseType: () => false})

• use the forceType option or Cite.parse.data[Async]() with the desired type

Cite.input(data, {forceType: '@other/url+type'})
Cite.parse.data(data, '@other/url+type')

---

A general solution would be to create a separate category of parsers with generic types, to catch all leftovers. This would include all @else and @empty types. This could also warrant the creation of an entire category system for parsers, as there already is a separate system for native parsers.

[larsgw]

I'm working on a different system: types will now be able to extend other types. Example:

Cite.parse.add('@wikidata/url', {
  dataType: 'String',
  parseType: () => false,
  extends: '@else/url'
})

The Cite.parse.add() function will probably also change before v0.4.0, but that's for another day.

This will register @wikidata/url as a subclass of @else/url. If a given input matches @else/url, it will now first check if subclasses also match, and if they do, give it that type. Note that this assumes every form of input matching @wikidata/url also matches @else/url, i.e.:

If types (or rather the criteria in the type parsers) overlap, however, this wouldn't work.

In that case, I recommend making the type parser criteria more specific, if possible.

---

Note: Removing parsers (instead of stubbing them, like above) will also be possible.

I still have to figure out logic for what happens when a type is registered as extending a type that doesn't exist.