Issue title: Normative statements for the vocabulary association mechanism?
 Issue body: The [§11 Vocabulary Association Mechanism](https://w3c.github.io/epub-specs/epub33/rs/#sec-vocab-assoc) section is altogether a _MAY_; it starts with:

> [Reading systems](https://www.w3.org/TR/epub-33/#dfn-epub-reading-system) MAY support [vocabulary association mechanisms](https://www.w3.org/TR/epub-33/#sec-vocab-assoc) [[epub-33](https://w3c.github.io/epub-specs/epub33/rs/#bib-epub-33)] in [EPUB content documents](https://www.w3.org/TR/epub-33/#dfn-epub-content-document).

We actually know that RS-s almost never implement this. It is therefore a bit disturbing to see the section full of _MUST_ statements (which all would also require tests). It all sounds very "aspirational" to me. Wouldn't it be better to rephrase this section? Maybe a simple solution to replace all the _MUST_ statements by plain, lower case "must"-s?

We had a similar situation with, e.g., MOL, which is also an optional feature, but the section contains lots of _MUST_-s. But this section is not optional in terms of _SHOULD_, but in terms of _MAY_. Also, we know that MOL is implemented by RS-s (although not by all).

 Comments: 
 Comment 0: Not sure how this would make sense? If you have nothing but informative statements, then why not let reading systems make up their own processing of optional features? Interop is out the window anyway.

> which all would also require tests

Why do we need to test the requirements of optional features? That's making the atomic statements more important than their overall support statement.
 Comment 1: > Why do we need to test the requirements of optional features? That's making the atomic statements more important than their overall support statement.

That is actually the problem: if we have _MUST_ statements, we are supposed to provide tests to see if they are properly implemented by a RS that does Voc. Associations. In theory, a _MUST_ statement without a test is a no-no...
 Comment 2: > we are supposed to provide tests to see if they are properly implemented by a RS that does Voc. Associations

Ya, but the problem with lowercasing all the requirements is that we're turning an optional feature into an informative description. That can't be any better, can it?

That means you don't actually have to respect prefix declarations, for example, since it would no longer be a real requirement.
 Comment 3: This is a lot like the pub manifest proof problem. We seem to require our own implementation to show that you can do these things, since there isn't a verifiable result you can check for in reading systems.
 Comment 4: What if we rewrite the whole section as a set of steps for calculating an expanded property. It would probably be a lot clearer. Could we then get away with making it more of a function rather than a series of MUSTs, so introduce it like:

> To obtain an expanded `property` value ... apply the following steps:

Would that dodge the testing requirements?
 Comment 5: When authors override reserved prefixes, do existing RSes use predefined URLs for reserved prefixes anyway?
 Comment 6: > When authors override reserved prefixes, do existing RSes use predefined URLs for reserved prefixes anyway?

I think that is the case, yes. 
 Comment 7: According to the spec, the author declaration takes precedence:

> Reading systems MUST use the URLs defined for locally overridden prefixes (using the prefix attribute) when encountered.

There were complaints a long time back that we could clobber someone's legitimate use of a prefix by reserving it for own purposes in the future.
 Comment 8: The issue was discussed in a [meeting](https://www.w3.org/publishing/groups/epub-wg/Meetings/Minutes/2022-08-04-epub#section2) on 2022-08-04

List of resolutions:

- ***[Resolution No. 1](https://www.w3.org/publishing/groups/epub-wg/Meetings/Minutes/2022-08-04-epub#resolution1):  The WG supports merging #2379 pending approval from the assigned reviewers..***

<details><summary><i>View the transcript</i></summary>

### 2. Re-implement vocabulary association mechanisms as an algorithm (pr epub-specs#2379)

_See github pull request [epub-specs#2379](https://github.com/w3c/epub-specs/pull/2379)._




_See github issue [epub-specs#2378](https://github.com/w3c/epub-specs/issues/2378)._




_See github issue [epub-specs#2382](https://github.com/w3c/epub-specs/issues/2382)._




**Dave Cramer:** there are a couple issues associated with this (#2378, #2382).  
… this is very technical, I wish mgarrish were here to explain.  
… doesn't really seems to change how the spec works, more an editorial change.  
… seems like they were just looking for WG approval before merging, even though most of us probably won't have strong opinions on this.  
… i'm generally in favor of explaining things in an algorithmic fashion rather than hard to understand paragraphs.  
… maybe we just say that we don't have objection to merging this pending github reviews?.  

> **Proposed resolution: The WG supports merging #2379 pending approval from the assigned reviewers..** *(Dave Cramer)*

> *Dave Cramer:* +1.

> *Matthew Chan:* +1.

> *Brady Duga:* +1.

> *Toshiaki Koike:* +1.

> *Shinya Takami (高見真也):* +1.

> ***Resolution #1: The WG supports merging #2379 pending approval from the assigned reviewers..***

</details>
{'source': 'GithubIssues', 'repo_name_with_owner': 'w3c/epub-specs', 'issue_id': 1320364545, 'repo_stars': 109.0}