Publishing Working Group Telco — Minutes

Date: 2019-11-04

Attendees

Present: Ivan Herman, Dave Cramer, George Kerscher, Mateus Teixeira, Matt Garrish, Wendy Reid, Deborah Kaplan, Ben Schroeter, Garth Conboy, Marisa DeMeglio, Romain Deltour, Franco Alvarado, Avneesh Singh, Joshua Pyle, Benjamin Young, Nellie McKesson, Charles LaPierre, Rachel Comerford, Brady Duga, Bill Kasdorf, Gregorio Pellegrino

Regrets: Luc Audrain, Geoff Jukes

Guests:

Chair: Garth Conboy

Scribe(s): Mateus Teixeira

Garth Conboy: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-10-21-pwg

Garth Conboy: first, approving minutes… any corrections or objections?
… minutes approved

Resolution #1: last week’s minutes accepted

1. last manifest PR-s

Garth Conboy: first on the agenda, review changes to pub manifest (issue 138, PR 131)

1.1. duplicate URLs in reading order and resource list

Garth Conboy: https://github.com/w3c/pub-manifest/issues/138

Garth Conboy: https://github.com/w3c/pub-manifest/pull/131 (corresponding PR)

Matt Garrish: a number of issues came up last week… dauwhe had raised a couple of questions… going through algo to implement the spec
… the major ones in 138 are that we’re not going to have a MUST NOT on fragment ids on manifest level, but could be restricted at the profile level
… the other one (PR 131) also deals with publication of resources in reading order and resource list
… we had “MUST NOT” but we will leave it at “SHOULD NOT”… if it’s there, we won’t mess around with your reading order
… strongly advised that you don’t declare resources multiple times in reading order… leads to ambiguity
… we want to generally avoid that issue
… other than that, the changes were mostly editorial cleanup
… to recap: fragment ids are allowed, and you can declare multiple resources, and it will be a warning (still)
… we can discuss the resource issues now… i don’t think we need to restrict fragment ids at the publication level

Garth Conboy: nobody on the queue… ivan made an off comment on alternate issues… what did you mean?

Ivan Herman: we also had an issue in the last few days on what happens if you provide an alternate [?]

Matt Garrish: choosing alternates is issue 133… separate from 138

Garth Conboy: let’s stick with 138 for the moment
… nobody on the queue… dauwhe, you had chimed in on this issue. are you happy with where we are?

Dave Cramer: yes, i think allowing fragment ids is important, but i’m fine with the decision on duplicate resources… when we make restrictions I want us to be very conscious about what we’re restricting and why

Garth Conboy: ok, let’s consider that folks are happy with 138… mattg, want to cover 133?

1.2. choosing alternatives

Matt Garrish: https://github.com/w3c/pub-manifest/issues/133

Matt Garrish: this is about what to make about alternate resources… saying they have to be unique on one property and the UA can make the choice… but we don’t talk about what the unique properties are, how the UA goes about picking them… essentially, it’s two questions: we have encoding format, but no properties for selecting alternatives? what do we need here? … what are we selecting from and what is the process for selecting them?
… should figure this out before going to CR… unfortunately, i don’t know what the best resolution is… seems like a case for media queries, but it might be too deep in the weeds… for selecting them, my general thought is we follow HTML–the UA picks the one it can handle, and if it can’t, you get an error message… without going resource to resource one by one
… those are the questions

Dave Cramer: using this as a general purpose mechanism makes me a little nervous… reminds me of multiple renditions in EPUB… and how to present a bunch of complex choices to users…

Ivan Herman: +1 to dauwhe

Rachel Comerford: +1 dauwhe

Dave Cramer: this seems like an entirely good thing to point to media overlays, which sort of augment rather than replace the underlying content, but defining a mechanism to provide an entirely different primary content experience seems like a world of complexity

Mateus Teixeira: +1

Garth Conboy: you had me at multiple renditions

Marisa DeMeglio: originally, with alternate, we didn’t think about offering more than one… then with audiobooks it came up that you can have a pure HTML alternate or synched text alternate…
… there’s sort of an edge case here, which is if you have two alternates… like deep voice or high pitched voice… and you want a consistent experience, so the selection should be the default… and the encoded format wouldn’t work in this case because it would be the same for either option
… the other thing was for it to be consistent with the way we write about URLs, to be consistent with the rest of our data values… i don’t know what we should choose… but i’m wary about inventing a selection mechanism… HTML-style audio fallback wouldn’t really work here either… seems like a very complicated issue

Ivan Herman: to add to the complication, we have to remind ourselves that the alternate originally appeared for audiobooks, and we decided other types of publication might use it, so we pushed it to pub manifest
… so any general mechanism defined here would be an absolute nightmare… so it should be strictly profile-specific, because otherwise there is no end to it

Garth Conboy: continuing from ivan… avoiding the nightmare seems like a good thing… is making it profile-specific a way to get around it for now?

Ivan Herman: yes, but we will need to say something about audiobooks… the nightmare is then more manageable in the general case, but we still need to define it… also depends on the kind of resource… audio is one thing, but also cover page alternates (images), which would possibly be a different kind of mechanism… like picking based on resolution
… so not only dependent on profile, but also the role of the resource for which the alternate is defined… it’s a multiple-dimension thing

Matt Garrish: this is sort of what my question is… does it belong in pub manifest or can it be defined for synched media? if that’s the primary use case, wouldn’t it be better to define it in that spec?

Ivan Herman: +1 to Avneesh

Avneesh Singh: i think that we should keep it as simple as possible, not get into a situation where we get into a nasty loop to define more and more things

Wendy Reid: +1

Avneesh Singh: we should keep the audiobook case simple

Ivan Herman: +10000 to Avneesh

Garth Conboy: so should we keep it only relevant to synched media?

Avneesh Singh: yes, and keep it specific to audio

Marisa DeMeglio: I don’t mind extending synched media to incorporate this, but i’m afraid it would be a very narrow solution, because as Avneesh said, you can have both HTML and audio, and it might get awkward on making that call… would rather not do anything… if there are so many books that can’t be disambiguated, then we realize that the standard has to accommodate more, but it doesn’t seem that pressing

Matt Garrish: I misunderstood, didn’t know there was an audiobook case here too… one thing we can do with it is say that alternate only provides different encoding formats, and leave it open to profiles to do more interesting things, and that’s it… it’s sort of open-ended at the moment what you’re supposed to make with it… the uses are not very well defined

Ivan Herman: we can make what Avneesh proposed to say that this version of this spec does not define anything, put it in a note in the document… and make it clear that future versions of the specs may come up with a more complex mechanism if there’s a need for it
… inventing things for use cases we don’t know about is not a good idea, but we know that this may require at some point a more complex mechanism, so we can make this note that we wait for use cases to come up

Garth Conboy: mattg, are you comfortable with that direction?

Matt Garrish: yes, just saying that we’re not defining anything at this point in time, and leave it to future versions and profiles

Garth Conboy: is that acceptable?

Marisa DeMeglio: yes, it’s ok. there is one accessibility use case about switching voices, but we need to do more research about it, and future versions of the spec could introduce a solution to that

Garth Conboy: nobody on the queue…. sounds like consensus
… anything else that comes to mind that would fall into recent substantive changes?

1.3. resolving prefixes in the manifest

Matt Garrish: https://github.com/w3c/pub-manifest/issues/141

Matt Garrish: yeah, there’s more
… 141, one ivan raised over the weekend, whether or not we have to resolve (URL) prefixes

Dave Cramer: NO

Ivan Herman: my answer is no…

Dave Cramer: NO

Matt Garrish: right, the answer is no, but just seeing if everyone is on board with it… we had made it a requirement in EPUB that they be resolved, and we learned it was not the best approach… it’s useful and certainly if you want json-ld processing it’s something you need, but let’s not get into validating and resolving them in our processing algorithm… let’s focus on the more useful part, creating some useful prefixes that people can use, and nothing

Mateus Teixeira: else

Garth Conboy: seems like consensus… anyone else want to chime in?
… I think “no” is where we are

Ivan Herman: right. What is our next step with this? Regarding predefined prefixes… knowing schema.org already predefines a number of prefixes… like dc and foaf, biblio… all predefined in schema.org
… do we want to add predefined prefixes in our own context?
… mattg and I were looking and some predefined ones in EPUB… maybe onix and marc would be useful?

Deborah Kaplan: https://www.loc.gov/marc/

Ivan Herman: that’s the only question, and we don’t need final list for CR because it doesn’t change the technical content of the final document in any way

Bill Kasdorf: i would advocate for keeping it informal for the extent of treating onix and marc as examples… particularly because we want it to be relevant for all kinds of publications, but we don’t want to single anything out.

Ivan Herman: the question is, which are the ones that are particularly and largely in use? Just to make the life of the user easier… there are three or four that from the outside may be useful, and it doesn’t cost anything to add them to the context

Bill Kasdorf: what’s the UA supposed to do with that

Ivan Herman: for internal representation, we don’t do anything with those… the question is, e.g., is there a reason for putting data into the manifest that is onix data?

Deborah Kaplan: agreeing with what Bill_Kasdorf says… there are a lot of prefixes that will be useful in specific contexts… there are gonna be field-specific prefixes in publishing, libraries, etc… and they won’t be there to be useful for the UA… they’re there because they identify the specific information/metadata… and the UA will probably have its own ways to handle them, but i don’t think we are going to be expecting that
… makes a lot of sense to point out specific ones that will be used a lot, but it makes less sense to make an exclusive list
… i am more in the example camp than in the specificity camp

Deborah Kaplan: MeSH, btw, is https://www.nlm.nih.gov/mesh/meshhome.html

Matt Garrish: there’s an argument here… if we’re expecting profiles for specific use cases, we should maybe wait until specific prefixes are needed… but the context document is easy to update… i don’t think it’s harmful… but let’s not just add things for the sake of having a list

Benjamin Young: https://w3c.github.io/pub-manifest/#extensibility-manifest-properties

Benjamin Young: agreed with mattg… this really should be part of the profile… the key practical scenario is that whatever we don’t add in the context in the profile will be added to the context of the individual publications… so we need to acknowledge that, and publishers should know. there is danger, though, that any prefix you pick and assign a URL could be changed, you kind of want to version this and put it through a publishing oversight…
… to make sure you’re not moving things… a community using them can suffer when moving those things underneath
… when we publish a new context, it really needs a new identifier

Bill Kasdorf: the reason I’m strongly in the example camp is that it shows what to do with those things… we don’t want to discourage use of prefixes just because they haven’t been defined… we should be agnostic

Ivan Herman: I have no problem with anything that was said… the only thing I am asking here that I don’t have the answer for… EPUB does have these four or five prefixes defined, some very IDPF-specific… is there an expectation in the community that those continue to be there because they were there in EPUB? maybe we can include them just to avoid problems

Deborah Kaplan: another concern with defining specific prefix vocabularies… it runs the risk of being culturally and nationally chauvinist… in the way we’re fairly bad about in standards in general… like marc being very US-specific, being anglophone, American or West-European…

Ivan Herman: +1 to deborah (maybe it should be +10000, because this is what I seem to use:-)

Wendy Reid: +1

Bill Kasdorf: +1 to Deborah

Deborah Kaplan: we are saying in the standard by putting it in the list that we think These Are Important

Matt Garrish: to the question about whether onix or marc are necessary… i’d have to research EPUB for that, but my gut feeling is “no”
… it was very EPUB-y and strange… I would say “no”… I don’t think the mechanisms they were used for would be useful for web publications

Ivan Herman: we can propose to close the issue without further action

Wendy Reid: +1

Ivan Herman: +1 Cover Mateus Teixeira: +1

Bill Kasdorf: +1

Romain Deltour: +1

Ric Wright: +1

David Stroup: +1

Deborah Kaplan: +1

Ivan Herman: anything else?

1.4. cover description always recommended?

Matt Garrish: https://github.com/w3c/pub-manifest/issues/145

Matt Garrish: yes, 145… i think this is coming to a solution… that we recommend both a name and a description for an image…
… like saying we need alt text and description for all images, which is not always true…
… recommend we point to WCAG… would be ideal if we could agree on this now, or wrap it up in the next couple of days
… not all covers are meaningful and need to be described or need extended descriptions…
… this becomes more of a guidance to the user and the author

Garth Conboy: https://github.com/w3c/pub-manifest/issues/145#issuecomment-549448461

Deborah Kaplan: flashing back to the long conversation we had about this when it first came up… i agree with the wording that you said should be changed… but a particular trick is that the problem is not any image needing to be described, but particular complex images
… we need to make a recommendation for how the UA should handle this information… and it should follow the standard rules…
… whether by linking to existing docs in an existing spec or stating here that meaningful images should be described… we need to have it somehow

Matt Garrish: I fully agree, that was my intention that we’d link… but i’m wondering about how much we should repeat… I hate doing that because it tends to introduce ambiguity… but we could explicitly point what we mean about “meaningful images” to WCAG

Deborah Kaplan: I would be ok with the approach, but this is a difficult problem because this is a domain-specific aspect of the art of alt text that people don’t understand… people don’t usually understand that the cover contains metadata and images that are usually decorative, but not always

Bill Kasdorf: this isn’t just about books, is it?

Deborah Kaplan: WCAG does not explain this carefully… it’s a set of guidelines, not about the art… it’s domain-specific enough that it could use a little help
… this is why I don’t like the concept of “complex” (fractals are complex, but decorative, for example)

Matt Garrish: I completely agree with dkaplan, but we should raise it with WCAG about adding a technique, bringing publishing issues across W3C

Deborah Kaplan: matt: +100000090000 for technique for book covers!!!

Charles LaPierre: +1 Agreed on book cover techniques!

Deborah Kaplan: also agreed with George: we called my CS book the dragon book, or sendmail the fruitbat book

George Kerscher: I have seen times where students refer to the book by the cover image… and we need enough information so that we can identify the book… and I agree with pointing to WCAG guidelines and bringing this up with them

Avneesh Singh: don’t know if WCAG would be ready to absorb it right away, cover is so specific to publishing… but this could go into best practices too… not to decide yet

Garth Conboy: this sounds like consensus…. mattg?

Matt Garrish: yes, this sounds like consensus, but we need to bring up a technique for covers with WCAG. These are the directions we can move forward with

Garth Conboy: great, sounds like at least rough consensus

2. Path to CR

Garth Conboy: next item is path to CR…

Garth Conboy: https://github.com/w3c/publ-wg/wiki/%5BPublishing-WG%5D-CR-Transition-for-pub-manifest-and-audiobooks

Ivan Herman: the wikI page in fact reflects the questions that we would have to answer when we ask for permission to go to CR
… there are lots of things there that have been collected, many things come from mattg like the changes, etc….
… first of all, I don’t think the WG should say “yes” to all the things there, but it should reflect some sort of consensus of the group
… we should review this and make sure the statements that are there reflect reality
… we need an agreement on this. as far as I can see, unless mattg comes up with new issues, we have closed all the issues at least on pub manifest–I think also audiobooks–and there’s some small editorial work to do, but I think we can say that the documents are ready
… we can go ahead, but we need this consensus….
… what we also need, where things get complicated…. there’s an implementation and testing strategy at the end of the page, but I am unsure whether what’s there is good enough…
… people who have more practice or volunteered could look at that text and give more details, because it sounds a little bit unclear
… from the implementation side, the one thing that has happened in the past few weeks, and which should be mentioned, is that the processing of the manifest, a relatively complex algorithm that reflects all the MUSTS and SHOULDS, etc…, that does have two experimental implementations (in javascript and typescript)… and it’s how we debugged the spec… but we should have more about that as well…
… including what exactly we should test, etc.
… just asking questions here… I don’t have the answers

Garth Conboy: talking a little about process… the things we need to do as a full WG as we’re heading to the CR process…

Ivan Herman: formally speaking, the WG needs a formal resolution to ask the Director for authorization for CR… and part of doing that is pasting this document in an issue where it can be discussed

Garth Conboy: so it’s important to have everyone read that with the expectation to make the decision as a WG next week

Ivan Herman: correct, but we need some more information in the implementation part, otherwise we risk getting sent back to the drawing board

Garth Conboy: next week we’ll come back hopefully without issues to cover, discuss the wiki a little further, and hopefully have consensus for CR

3. Resolutions

Resolution #1: last week’s minutes accepted