mattgarrish
commented
1 year ago Does it mean to say that the use of any role not defined either in the registry of role extensions or as a known custom extension role is deprecated? If yes, then I think being explicit would be preferable.
That can't be done because we can't normatively refer to those documents.
The collection element on its own is pointless - it's always been a vehicle for creating specialized types. The section contained the rules you had to follow to create new types, which is what we've removed. Part of creating a new type of collection was to register a role, but since we're no longer supporting creation it effectively freezes the registry without having to normatively deal with it (i.e., what exists remains valid, but nothing new can be added).
From a validation perspective, epubcheck should only allow the existing registry values. The element is essentially a dead-end moving forward, so neither registry will be added to anymore.
Or would it even make sense to deprecate the collection element altogether?
We'd potentially invalidate content that uses collections if we did that. There may not be a lot of content that uses them, but there are a lot of specifications that depend on the element (indexes, glossaries, etc.).
rdeltour
Section "Defining collection types" says:
What does it mean exactly that the creation is deprecated? Does it mean to say that the use of any role not defined either in the registry of role extensions or as a known custom extension role is deprecated? If yes, then I think being explicit would be preferable.
Or would it even make sense to deprecate the
collectionelement altogether? The RS spec says support for collection is OPTIONAL, so if we deprecate the element it won't change a thing (reading systems MAY support deprecated features).