Re-implement vocabulary association mechanisms as an algorithm

[mattgarrish]

Not looking for approval at this time. Just curious for early feedback on whether this makes sense as a replacement.

I kept the one requirement not to blow up when encountering unknown prefixes.

Fixes #2378
Fixes #2382

• Preview
• Diff

---

Preview | Diff

[iherman]

I think that is great. It would get around the issue of the awkward MUST statements and it works well.

Thanks!

[mattgarrish]

Okay, I think this is good to go now. The last commit mostly added explanations for all the steps. I also made a few tweaks to infra-ize things a bit more.

The two changes of note are:

• I've added an optional item to the epub:type processing list to get an expanded url. It was a bit strange to describe processing the attribute without mentioning that you could get an expanded value to process.
• I also added a paragraph to the top of the algorithm clarifying that it's not required to expand property values to use them. Reading systems that don't support the vocabulary association mechanisms can just treat them like strings.

[mattgarrish]

And as reading the diff is a bit of a nightmare, here's a link to the current section if you want to manually compare against the preview: https://www.w3.org/TR/epub-rs-33/#sec-vocab-assoc

[iherman]

I have sketched out an implementation in typescript, just to check. Emphasis is on "sketch", but it helped me to follow the infra stuff:-)

[iherman]

The issue was discussed in a meeting on 2022-08-04

List of resolutions:

• Resolution No. 1: The WG supports merging Re-implement vocabulary association mechanisms as an algorithm #2379 pending approval from the assigned reviewers..

View the transcript

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

See github pull request epub-specs#2379.

See github issue epub-specs#2378.

See github issue epub-specs#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..

[iherman]

Per WG resolution, we need an approval of at least @shiestyle and @dauwhe (@wareid and, I presume, @rdeltour being on vacations...). Shinya, Dave, could you do this, please?

[mattgarrish]

I think they gave us the green light to merge it once we are happy with it. I think the "reviewers" in this case means me and you, as it sound like the group is fine with whatever we resolve on for this given no one's hugely passionate about a feature that's only for internal reading system use... 😄