Meeting minutes
wendyreid: today we have some PRs that deserve attention
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
PR 2735 - w3c/epub-specs#2735
wendyreid: the next is about ITS attributes
ivan: 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
mgarrish: we were wondering if it would be easier to add extensions going forward
mgarrish: we would just add another extension section with optional reading system support
wendy: so we want to change this to an extension section?
… any opposition to merging this?
PR 2731 - w3c/epub-specs#2731
wendy: seeing none, we will move on
wendyreid: formulating the evaluation dates
mgarrish: 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?
AvneeshSingh: 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
mgarrish: maybe we keep a separate list of items that we would return to if we change conformance numbers
Hadrien: 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
mgarrish: I see what you're saying, but at this time we have no suggestion about how to express the date
Hadrien: as long as it is based on an existing format, we can work with it
George: identifying the date format seems like standards work
… if we change the conformance number, it gives us more freedom
CharlesL: 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
mgarrish: 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
AvneeshSingh: does the backward compatibility clause get violated if we make these kinds of changes
ivan: 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
CharlesL: 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
mgarrish: that is what this change does
wendyreid: This change is OK, but we shouldn't make it a must?
mgarrish: right now we will accept any date format from the date section, make it a "should" and see what happens
CharlesL: I don't know that we need to include the date/time, but its OK as long as the time is ISO standard
Hadrien: 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
<CharlesL> +1 to Hadrien
Wendy: any opposition to making this a "should" and adding date/time
AvneeshSingh: let's wait to merge this until after the Accessibility WG
<CharlesL> I also agree this should be a MUST
duga: I prefer making it a must and updating the conformance number
mgarrish: if it isn't a must, ACE can bump it up as a serious error
shiestyle: 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
mgarrish: it isn't required, but it is a good record, for knowing when their accessibility was last done
mgarrish: the more important part is getting the accessibility review is done
wendyreid: if you're running ACE, you'll get an error, but not from EPUB check
CharlesL: does ONIX have a similar field?
<wendyreid> https://
wendyreid: 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> w3c/
wendyreid: adding pagebreak source to the metadata vocabulary property
Hadrien: 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
CharlesL: this is useful when the end user is creating references to data
… it is more for citing passages by students or scholarly publishing
wendyreid: 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
mgarrish: 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
wendyreid: is there any opposition to merging this as a step forward?
… alright, cool
… we don't have time for the last one
mgarrish: 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
wendyreid: I will put an "on hold" label on it
<LaurentLM> move to #pm-ann