Meeting minutes
Wendy Reid: today we have some PRs that deserve attention
PR 2742 - w3c/epub-specs#2742
<Wendy Reid> https://
Wendy Reid: the first one is about reserved prefixes
… this fixes a related issue about reserved prefixes and obsoleting some that haven't been used
Matt Garrish: 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 Herman: 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
Matt Garrish: I think it is kind of silly that we have to retain these things but we have to think of backward compatibility
Matt Garrish: if we take them out I would love to know who ever implemented these things
Charles LaPierre: does it make sense to delete the ones without a valid link
Matt Garrish: if you don't know about these identifiers, it is helpful to add a proper link that we can maintain
George Kerscher: Why don't we just get rid of it? If someone is using it then they can complain
Wendy Reid: that is compelling for the ones no longer maintained
Ivan Herman: 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
Matt Garrish: we can never be sure it is used
Brady 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
Matt Garrish: then we need to decide if we flag all deprecated features
<Charles LaPierre> +1 to Brady's suggestion. and bring up a warning in EPUBCheck
Wendy Reid: it might not be bad if epub check flags deprecated prefixes
Brady Duga: if we really want links we can use internet archive or just let other people look there
Ivan Herman: let's keep it as we have it in the PR, but for our next charter, let ourselves delete some unused stuff
Brady Duga: that makes sense, can we track the things we would like to delete? So we can go back to it?
Ivan Herman: 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
Matt Garrish: would that suggest we change the PR and put them in the deprecated section?
Ivan Herman: to be procedural, we should pass a resolution that deprecated features will be removed in our next charter
<Wendy Reid> Proposed: Deprecated features in EPUB 3.4 will be removed in future versions of the spec.
<Matt Garrish> +1
<Susan Neuhaus> +1
<Ivan Herman> +1
<Wendy Reid> +1
<Charles LaPierre> +1
<Brady Duga> +1
<Shinya Takami> +1
<Hadrien Gardeur> +1
<George Kerscher> +1
<Masakazu Kitahara> +1
<Toshiaki Koike> +1
RESOLUTION: Deprecated features in EPUB 3.4 will be removed in future versions of the spec.
Hadrien Gardeur: 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 Herman: this would be good for the f2f
Wendy Reid: it would be good to open an issue so people can think about it ahead of time
Wendy Reid: matt will have to make some edits to that PR
PR 2735 - w3c/epub-specs#2735
Wendy Reid: the next is about ITS attributes
Ivan Herman: there is a set of attributes that look like the ARIA attributes defined by the W3C for internationalization
… like setting the translation of terms, setting aside language portions
… these attributes are not recognized in epub or an extension to HTML
… i ran into this problem changing a document into Chinese
… it was written with 3 different director sets
… epubcheck rejects this because it is not accepted
Matt Garrish: we were wondering if it would be easier to add extensions going forward
Matt Garrish: we would just add another extension section with optional reading system support
Wendy Reid: so we want to change this to an extension section?
… any opposition to merging this?
PR 2731 - w3c/epub-specs#2731
Wendy Reid: seeing none, we will move on
Wendy Reid: formulating the evaluation dates
Matt Garrish: we didn't formalize a format for the date
… the problem is how to localize the date when we don't know the format of the date
… we could choose an existing format, and likely exclude the time
… and will this affect existing content
… and have we already committed to bumping the conformance number
… if not, this affect all existing content that conforms to the current version
… are we proceeding on requiring access mode sufficient and is it OK to add this when we bump up the number?
Avneesh Singh: we will discuss this in an upcoming meeting in the WG
… we will elevate it to a must follow and see how the community responds
… we are moving ahead with precautions ACE will flag it
… I am worried if we make the date a must at this point, we would get downstream errors
Matt Garrish: maybe we keep a separate list of items that we would return to if we change conformance numbers
Hadrien Gardeur: I don't see the point of this change as a must statement
… what is the value of this change to the user? When you localize the date
… you can choose what to display. At best this could be a "should"
… especially since there are potential validation problems
Matt Garrish: I see what you're saying, but at this time we have no suggestion about how to express the date
Hadrien Gardeur: as long as it is based on an existing format, we can work with it
George Kerscher: identifying the date format seems like standards work
… if we change the conformance number, it gives us more freedom
Charles LaPierre: the reading system or bookstore can always display it how they choose
… having a standard format will help it be changed to the local language
… so we need to go with the ISO
… as far as requiring it, we can start requiring, it has been optional, but we tell everyone to put it in
… we can discuss this in our next WG call
… I agree with George that we should plan to update the conformance number
Matt Garrish: if we don't make it a requirement we will never really be sure what we get when processing this data
… if we made it a must we would know we could trust the required date format after a certain point
… we don't know what the date will contain if we don't do some testing
Avneesh Singh: does the backward compatibility clause get violated if we make these kinds of changes
Ivan Herman: the conformance in the charter never really explicitly refers to the accessibility metadata, we are in a gray area
… it refers to in practice what epub check checks
Charles LaPierre: similar to "conforms to" if you have that then you must put in "certified by"
… maybe it could be if you include a certified date it should conform to an ISO standard
Matt Garrish: that is what this change does
Wendy Reid: This change is OK, but we shouldn't make it a must?
Matt Garrish: right now we will accept any date format from the date section, make it a "should" and see what happens
Charles LaPierre: I don't know that we need to include the date/time, but its OK as long as the time is ISO standard
Hadrien Gardeur: One of the reasons we should be looser about the format is we don't know what people have in their systems
… if people use a timezone for instance, we can deal with that
… we shouldn't force things that aren't necessary
<Charles LaPierre> +1 to Hadrien Gardeur
Wendy Reid: any opposition to making this a "should" and adding date/time
Avneesh Singh: let's wait to merge this until after the Accessibility WG
<Charles LaPierre> I also agree this should be a MUST
Brady Duga: I prefer making it a must and updating the conformance number
Matt Garrish: if it isn't a must, ACE can bump it up as a serious error
Shinya Takami: This date is not mandatory, right?
… from a publisher's point of view we generate epub, and we have to change it because the date appeared, many publishers will use this, but this looks like tricky metadata
Matt Garrish: it isn't required, but it is a good record, for knowing when their accessibility was last done
Matt Garrish: the more important part is getting the accessibility review is done
Wendy Reid: if you're running ACE, you'll get an error, but not from EPUB check
Charles LaPierre: does ONIX have a similar field?
<Wendy Reid> https://
Wendy Reid: it is number 91, latest accessibility assessment date
… so we'll let the Accessibility TF talk about this first, if they are happy, then we can merge it
PR 2730 - w3c/epub-specs#2730
<Ivan Herman> w3c/
Wendy Reid: adding pagebreak source to the metadata vocabulary property
Hadrien Gardeur: a general comment, how useful is this?
… in practice I don't see how we can use this if we get an identifier we don't know about
… we can't properly display it. It is hard to make use of this
… in ONIX it is pretty coming to know about the other format of a book
… in a EPUB context I'm not sure what to do with this
Charles LaPierre: this is useful when the end user is creating references to data
… it is more for citing passages by students or scholarly publishing
Wendy Reid: it doesn't have to be an ISBN, maybe we can be more specific and suggest a URL
… I see your point about this being difficult to display
… maybe this is also a question for the annotations group
Matt Garrish: the usefulness if for education purposes
… in terms of adding this to the spec. This is trying to address cases
… when a book has no print source
… this is an invitation to make our own standard and no rely on a dc:source
… we can continue working on improving it
Wendy Reid: is there any opposition to merging this as a step forward?
… alright, cool
… we don't have time for the last one
Matt Garrish: I'm holding off on this it is bound up in us bumping up the conformance version
… a question of making AccessModeSufficient a must and compatible with the current ISO version
… we may want to wait on this
Wendy Reid: I will put an "on hold" label on it
<Laurent Le Meur> move to #pm-ann