Cataloguing unregistered media types and parameters

[bansp]

If they are registered with some working pipeline architectures or recognized by the Switchboard, we want to catalogue media types and parameters, because they may be (or are) emerging best practices and then we

• perhaps need an attribute to distinguish them from those formally registered
• and I wonder if we should handle the potential parameters in some special fashion other than using them as part of the media type, as we do now (and by 'special fashion' I simply mean a separate container, probably an element to use an attribute for the value range.

[bansp]

At the meeting today, we gave green light to this. Setting priority to try to handle this by the next meeting (no promises).

[bansp]

To be more precise, next to

<mimeType>application/xml</mimeType>

we would have something like

<mimeType status="unregistered">application/folia+xml</mimeType>

and then, instead of what should be:

<mimeType status="unregistered">application/tei+xml;format-variant=tei-iso-spoken</mimeType>

-- which is not fully precise, because the "application/tei+xml" is by all means registered -- we could do, with a twist, the following :

<mimeType value="application/tei+xml">
  <mimeParam name="format-variant" value="tei-iso-spoken" status="unregistered"/>
</mimeType>

and we could (or should) push a step further, and do also:

<mimeType value="application/tei+xml">
  <mimeParam name="format-variant" value="tei-iso-spoken" status="unregistered"/>
  <mimeParam name="tokenized" value="{0,1}" status="unregistered"/>
</mimeType>

-- with a convention that {} embrace a set of values.

A further step is to identify the registering entity (rather than just saying "yes" or "no"), and have the @registered attribute as obligatory, and do:

<mimeType registered="IANA">application/xml</mimeType>

and then we would have something like

<mimeType registered="CLARIN">application/folia+xml</mimeType>

(it could also be @registered="no", of course, but see below)

Let's consider one further hypothetical step:

<mimeType value="application/tei+xml" registered="IANA">
  <mimeParam name="format-variant" value="tei-iso-spoken" registered="CLARIN"/>
  <mimeParam name="tokenized" value="{0,1}" registered="CLARIN"/>
</mimeType>

The final form

• identifies registered and unregistered media types
  • subclassing "community best practices", in this case pertaining to WebLicht and friends, but there's no stopping us from identifying parameters in use in, say, DARIAH, should we extend the coverage beyond CLARIN
• makes it possible to subclass parameters and sort them by name and/or value
• makes an implicit assumption that I quite like, that apart from registering namespace identifiers, the CSC also acts as a community registration authority for e.g. media type parameters -- this is a good stepping stone for upgrading wild parameters to the status of IANA-blessed, with some further work.

[bansp]

Meeting decision: we'll see if the CSC has anything to suggest here, and may at some point split this into individual tasks (processing in various ways -- at least two tasks: redefining the XPaths and providing a way to aggregate the parameters in some way; redoing the schema; checking what we can provide via the API and how).

[bansp]

Meeting decision: I'll hack at this in a separate branch.

[bansp]

Meeting decision: move to the next milestone.

[bansp]

I fully concur with the above decision: move to the next milestone.

[bansp]

Re-read, potentially open a new branch for this.

[bansp]

This is connected to #157

[bansp]

I am prioritising this one for myself, not to lose it from my sights.

[bansp]

This ticket is connected to #157 .

[bansp]

One stumbling block above was consultation with the SIC. I think the order should be different: first a prototype, then consultation. Otherwise the members will not be sure what they are being consulted about.

BUT the prototype has to come post-CAC, or in a separate branch.