May be related to 16611

We should clarify the relationship between parent and subsystem strings (using a dot to separate, etc.) and remove mention of capability detection (bug 16611).

I would like to see specifics on how either capability detection is done, or how it should be added to Key System format. I am most interested in selective output control features and robustness levels, for example com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.

(In reply to comment #3)
> I would like to see specifics on how either capability detection is done, or
> how it should be added to Key System format. I am most interested in selective
> output control features and robustness levels, for example
> com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.

This was covered by bug 16611. The last update was:
"We propose not overloading key system strings with capability detection. We should consider if we need a separate capability detection system."

(In reply to comment #4)
> (In reply to comment #3)
> > I would like to see specifics on how either capability detection is done, or
> > how it should be added to Key System format. I am most interested in selective
> > output control features and robustness levels, for example
> > com.example.cdm.robust, com.example.cdm.robust_selectable_digital_output, etc.
> 
> This was covered by bug 16611. The last update was:
> "We propose not overloading key system strings with capability detection. We
> should consider if we need a separate capability detection system."

I should be more clear. Let's start considering it ASAP.  Those are the capabilities I am currently interested in, although the list might be extended in the future. I am not clear why adding it to the Key System format would not work. I have not been able to glean it from the minutes so far.

Issue 20798 relates to case sensitivity of the string.

What needs to be done here? Adrian suggests some concrete changes in Comment 2. The rest of the discussion seems to focus on capability detection, which should be covered in another bug - possibly bug 16611.

We discussed this in the F2F: I believe that the consensus was that we didn't need to complexity of the prefix matching for keysystem strings. Implementers can use whichever reverse-domain strings they want.

We should monitor what capability detection sites want and try to resolve those as they arise.

My proposal is to remove the references to com.example.somesystem.1_5.

It was also pointed out at the F2F that if version detection was supported in some way, "supports minimum version" might be the more helpful thing to check instead of exact version matching.

I agree that the use cases are probably better served with some type of feature detection and support removing references to versions in key systems [1].

I think there might still be use cases for some type of structure. For example, some key systems may choose to expose parent systems, such as "com.example", via isTypeSupported(). For those key systems that do, I think UAs should also expose them, though we don't need to specify exact variations in the spec.

The current draft does not actually say much about prefix matching or subsystems (v0.1b said a bit more). After deleting the version references, it might be good to provide a non-normative note that there may be such variations and that UAs should pass through variations for key systems that support it.

[1] Key System definition, isTypeSupported() examples, Selecting a Supported Key System example

Changeset -> https://dvcs.w3.org/hg/html-media/rev/da1d34e19d4f