epub-specs
epub-specs copied to clipboard
w3c
Clarify the purpose of the reserved prefixes
This pull request adds an additional usage column to the reserved prefixes tables to explain the purpose of each.
Despite my personal loathing of the dead prefixes, I've left them for now with an advisory against further use of them.
For the xsd: prefixes, I noticed that the property definitions are covered by the allowed values definition. It called out xmlschemas-2 but didn't mention the prefix, so I've added a reference to it there. The other place we reference xsd datatypes is in the ebnf definitions. For those, I've added an additional line to source the datatypes. That should cover all cases so we aren't just dropping in xsd:* values without any context.
I don't figure this counts as a substantive change, so I'm not recording it in the change log.
Fixes #2739
I don't figure this counts as a substantive change, so I'm not recording it in the change log.
+1 to that.
However unlikely this occurrence would be, it would violate the letter of our charter.😒
Ya, it's just the unlikelihood that these prefixes have ever been, or will ever be, used that bothers me. But that was our fault for adding them before there was any proof they would be used, alas.
But having the extra column where we can point out their lack of use is good enough for me. It's not an issue worth spending any time arguing over.
This was discussed during the pmwg meeting on 26 June 2025.
View the transcript
PR 2742 - w3c/epub-specs#2742
<wendyreid> https://
wendyreid: the first one is about reserved prefixes
… this fixes a related issue about reserved prefixes and obsoleting some that haven't been used
mgarrish: some of these links go to a 404
… what can we do to help people understand what these are now that there are not relevant
… we added a new column to the table with more explanation
ivan: how will we be handling this kind of thing?
… the vocabulary is a good example. We didn't take it out
… because of backward compatibility
… how long do we want to keep things like this in the specification?
… if we were not dedicated to backward compatibility we would probably remove things like this
mgarrish: I think it is kind of silly that we have to retain these things but we have to think of backward compatibility
mgarrish: if we take them out I would love to know who ever implemented these things
CharlesL: does it make sense to delete the ones without a valid link
mgarrish: if you don't know about these identifiers, it is helpful to add a proper link that we can maintain
George: Why don't we just get rid of it? If someone is using it then they can complain
wendyreid: that is compelling for the ones no longer maintained
ivan: the charter says that any 3.1 3.3 document should be backward compatible in 3.4
… then epubcheck might flag these terms as errors
… we will never know if anyone uses these
mgarrish: we can never be sure it is used
duga: alternatively could we say "this is a collection of deprecated prefixes"
… they still exist in the spec, just don't use them
… they are still in epub check and we just never remove them
mgarrish: then we need to decide if we flag all deprecated features
<CharlesL> +1 to Brady's suggestion. and bring up a warning in EPUBCheck
wendyreid: it might not be bad if epub check flags deprecated prefixes
duga: if we really want links we can use internet archive or just let other people look there
ivan: let's keep it as we have it in the PR, but for our next charter, let ourselves delete some unused stuff
duga: that makes sense, can we track the things we would like to delete? So we can go back to it?
ivan: maybe the deprecated flag would be the best way to do that
… then we can add "everything will be retained except deprecated features" in the next charter
mgarrish: would that suggest we change the PR and put them in the deprecated section?
ivan: to be procedural, we should pass a resolution that deprecated features will be removed in our next charter
<wendyreid> Proposed: Deprecated features in EPUB 3.4 will be removed in future versions of the spec.
<mgarrish> +1
<sue-neu> +1
<ivan> +1
<wendyreid> +1
<CharlesL> +1
<duga> +1
<shiestyle> +1
<Hadrien> +1
<George> +1
<MasakazuKitahara> +1
<toshiakikoike> +1
RESOLUTION: Deprecated features in EPUB 3.4 will be removed in future versions of the spec.
hadrien: I have a somewhat long list of things I'd like to see deprecated
… what is the best course of action?
… I did a presentation on the misuse of some properties
… some of it comes from the work of the comics group
ivan: this would be good for the f2f
wendyreid: it would be good to open an issue so people can think about it ahead of time
wendyreid: matt will have to make some edits to that PR
The prefixes are now in the deprecated features section, as discussed in the last call, so merging this now.