Publishing Working Group F2F in Fukuoka — First day -- 16 Sep 2019

<wendyreid> Meeting: Publishing Working Group F2F Day 1

<wendyreid> Chair: Wendy

<wendyreid> Date: 2019-09-16

<wendyreid> Agenda: https://docs.google.com/document/d/1Q8PUjzMY04peuYZdTkA6A0BBoFea_BSK4ygJlphkzh8/edit

<romain> present?

<toshiakikoike> presetn+

<JuanCorona> muting/unmuting for now to prevent feedback

<inserted> scribenick: marisa

scribe+ marisa

wendyreid: going to CR for audiobooks, pub-manifest, sync media update
... meeting with aria and mathML groups too

laurent: at dev meetup tonight, we'll demonstrate comics on readium at 6pm. location TBA.

lightweight packaging format

<laurent> https://w3c.github.io/lpf/

laurent: draft note is available. shows how to put the pieces together and transmit them. small spec with specific use cases. main use cases explained in the doc.
... provide the finalized packaged publication from the publisher to the conversion house. useful for audio books going between the publisher and audio studio
... can also be used to download packaged publication from the distribution point to the user agent
... the spec goes over some very simple terminology, originating from epub 3.2 or web pub document

<laudrain> W3C Developer Meetup – Argos D, 1F, 18:00 – 20:30

laurent: based on zip
... viewed as an iso standard
... we defined a file and dir structure for what ppl have to put inside the zip. it's totally compatible with the packaging of the pub manifest.
... we have specified a standard name for the manifest ('publication.json'). an html entry page, if present, has to be called 'index.html'
... manifest could be embedded inside primary entry page. only one of manifest or entry page are mandatory.
... these two core files must not be encrypted
... the zip also contains all the resources of the publication, and they may live in any internal folder of the zip
... resources may be compressed
... note that streaming compressed audio files is more complex and we recommend to not compress them
... there is an algorithm to extract the manifest from this file, taken from web pub document and simplified
... UA conformance section: UA must be capable of exploiting the archive format and opening and processing the manifest
... placeholder for examples
... the file extension is .lpf and the mime type is application/lpf+zip
... right now, each bookseller has its own requirements for how creators should submit their content. this should solve this problem.

dauwhe: UA conformance section - can these statements naturally lead to tests? epub spec is not successful in this regard.
... to support LPF, all you have to do is be able to access the files i the zip and present them to the next step in the processing chain

<romain> +1, "is capable of exploiting the archive format and file structure" sound too vague to be testable?

dauwhe: is this only a subset of a web publication user agent

laurent: if you are a UA capable of supporting web pub, you don't need to open a zip
... e.g. readium can open a zip and extract the manifest and expose the different resources as an internal web pub
... the two first steps may not be among the capabilities of a web pub UA
... bullet points could be more precise in referring to the previous sections in the same document

dauwhe: current structure is hard to write tests for

romain: is it backwards compatible with the packing spec in epub?

laurent: yes totally compatible
... we could have zip with an epub and then add the manifest. then you'll have an LPF.
... it would have to have the mime type file at the start

romain: this packaging format may not work for all kinds of pubs - e.g. resources might be remote
... is there a way to document which part of the target publications do not work?

laurent: this is not a way to "freeze" a publication. it's a way to make an epub-lite and expose it on the web later. no link to https.
... if we want to fetch resources via hyperlink, you can still put the ? in there

<Makoto__> +q

laurent: it's intended to be used before the publication is visible on the web, i don't see the point

romain: it says LPF is used to exchange in-progress publications
... web pub is given as an example of a publication, but not all web publications can be packaged with LPF. there's a venn diagram here.

laurent: yes true
... does not cover the need to take any web pub and freeze it

romain: this could be stated more clearly

<Zakim> dauwhe, you wanted to discuss a second question

dauwhe: there's a statement: "a package must include all resources within the bounds of the publication... "
... i wonder if we should add a note addressing for example are we explicitly forbidding things like web fonts

<Makoto__> -q

dauwhe: is there some way to clarify that, like epub, there are certain exceptions for what can go in the package in general
... epub tends to provide more explicit lists of what types of things should be in the package

laurent: we should review the epub spec and extract some wording from there

laudrain: +1 to dauwhe re testing

<romain> Resources Location in EPUB: https://www.w3.org/publishing/epub32/epub-spec.html#sec-resource-locations

laudrain: testing must be very clear and this doc must be testable.
... epub 3.2 work can help here

<Makoto__> Here I would like to say that I'm sympathetic to Dave about non-testable requirements. IMHO, non-testable requirements are nothing but dreams.

duga: to go back to the web font topic, we initially said everything has to be in the package, and then we started making exceptions
... this was not planned nor architecturally sound. it was an escape route from the corner we'd backed ourselves into.
... go back to beginning: does everything have to go in the package? is a better approach than just poking holes and making exceptions

wendyreid: if the resource has changed, it's the fault of our relationship with the web
... it's ok to ref the web with the caveat that what you referenced may not be what you expected

CharlesL: can lightweight packaging format be used offline? e.g. on a USB stick in an offline environment?
... are we poking holes and creating a requirement to be online?

wendyreid: getting dangerously close to best practice territory
... responsibility lies with content creator

dauwhe: in the case of fonts, the web knows what to do if you can't find a font

mattg: a lot of this are prob things that we should discuss in regards to audiobooks
... this spec may not be where we solve these questions

<George> Because testing is so important, is it possible to incorporate the tests into the spec instead of having testing being derived after the fact?

wendyreid: many audiobooks do reference resources on the web due to sheer size and streaming feature

George: i'm wondering about dauwhe's testing questions - can we figure out which tests we would be looking at as the spec develops, rather than writing the spec first and coming up with tests later?

romain: +1 to mattg re not solving these things in this particular spec
... idea to have a manifest property that indicates whether it is packagable or not. might be awkward though.
... i think we should loosen the current restriction

laurent: we can loosen the spec - we specify that URLs in reading order must be relative

<Makoto__> I would like to drop User Agent Conformance.

laurent: we can say if we see an absolute URL, we won't require it to be in the package

<Makoto__> +q

Makoto__: i've been involved in OPC (open xml package format)
... conformance requirements in applications are difficult and dangerous to specify
... we should only provide data conformance
... if we are going to spend a lot of time creating test cases and methodology, we should stay away from UA conformance. it's a waste of time.
... at least 3 formats have tried this and failed

dauwhe: +1 to this idea
... it seems impossible to test, and i'm not sure what testing gives us in this case. if the application cannot process this format, then it is not conformant.
... aka how would you write a bad implementation of this spec - what would it do wrong

laurent: if you don't get the manifest in any situation...

dauwhe: then you can't do any further processing and you're stuck
... if you want to work with this data - we've described the format in enough data, so have at it, devs

laurent: the UA conformance here is paraphrasing the description of the format in other sections. not so useful.

romain: one thing we can test is obtaining the manifest, because there is an algo for it

mattg: not to make light of testing, if it's just a note, there's no TR process

<Makoto__> Then, the shorter, the better.

wendyreid: i will write a proposal to remove UA conformance section

laudrain: i wonder if there will be an AudioBookCheck (a la epubcheck) - then we will need some conformance verification for the audiobook spec *and* the packaging spec
... some tests would have to be written

romain: there are two things here - UA conformance and content conformance. we're talking about eliminating the former, not the latter.

dauwhe: packaging part should be simple and difficult to screw up

<wendyreid> Proposed: Remove the User Agent Conformance section from LPF.

<Rachel> +1

<wendyreid> +1

dauwhe: web world less interested in validating things; rather, let's define what happens when things go wrong

<toshiakikoike> +1

<JunGamo> +1

<duga> +1

<Makoto__> +1

<dauwhe> +1

<mattg> +1

<gpellegrino> +1

<laurent> 0

<bigbluehat> +1

<romain> +1

RESOLUTION: Remove the User Agent Conformance section from LPF.

<JuanCorona> +1

<CharlesL> 0

<laudrain> +1

wendyreid: laurent, are there any open issues or questions you need answers for?

laurent: no, just waiting for the finalization of the Publication Manifest document to get a link to it

horizontal reviews

<Makoto__> Deflate only? ZIP allows more efficient ones.

wendyreid: ping joining us. also i18n and a11y reviews happening.

<laurent> deflate only, in order to stay simple.

wendyreid: i18n mostly complete (thanks ivan! )
... the only outstanding question is the potential for multilingual text in the manifest
... ivan_'s resolution is that we prob require html markup to do so

mattg: one open issue under discussion w. addison and richard is whether or not valid/well-formed lang tags are required in all the places where we reference PCP 47
... a well-formed one only has to conform to the ???
... a valid one also has to have registered subtags

<Makoto__> Check against the BNF. That's enough, I would say.

mattg: the issue i had initially with it is that if it's well-formed then you can use whatever you want, so long as it is 2-8 chars (e.g. looks roughly like a lang tag)
... i18n group says well-formedness is what matters, not so much validity

<Makoto__> +q

dauwhe: i think well-formedness is fine. restricting authors without a really good reason is a bad idea.

Makoto__: +1 to dauwhe
... ppl don't specify strange language tags. they use standard ones. if they choose otherwise, ok, but it's not common.

mattg: i tend to agree that well-formedness is fine. should we say that the first part of the language tag should be valid, or do we not care at all?

<Makoto__> +q

CharlesL: do checkers need to be aware?

Makoto__: tts engine supports limited set of language tags, even if a tag is well-formed, there's no guarantee that it's supported

marisa: we are getting into best practice territory

dauwhe: +1 marisa

bigbluehat: do we need a resolution on the BCP-47 question?

wendyreid: no, we can just leave it be, go write your book in klingon

<wendyreid> Hi r12a we'd love to discuss, let's figure out a time :)

avneesh: thurs we will find if there are issues with a11y horizontal review. i have made a suggestion to the html files re issue #13.

bigbluehat: zip supports all kinds of compression algos - not just deflate
... we should be clear about what we support. likely that only supporting deflate will frustrate someone. we should be up front about why.

Makoto__: if we use a better algo, it could be 30% smaller. deflate has a big advantage though.

laurent: deflate was chosen for epub
... even if zip libraries offer a choice, end user tools usually don't
... we won't deflate binary content. just the text.
... the 30% size reduction is not worth the complexity

bigbluehat: why aren't we compressing media files?

laurent: we copied that part from epub
... when you want to stream from the zip, deflate makes it complex

<Ralph> [Ralph arrives (pseudo-Ivan), with apologies for being tardy]

bigbluehat: if we make these choices to suit end user tools, then what i produce with an end user tool should give me an LPF

laurent: use of deflate is a should

dauwhe: policing the zip details didn't help the epub world
... we should let the libraries do what they do

<laudrain> +1 to Dave

wendyreid: ping coming at 11 for horizontal review. anything from the ping survey to discuss ahead of time?

duga: someone added privacy + security sections. there were one or two comments to maybe delete.
... we have no APIs or protocols
... should be pretty straightforward

Ralph: duga is mostly right
... suspect ping will have looked at what metadata we're requiring in the manifest
... we're prob in good shape
... they will want to make sure we're not requiring things that will be misused

wendyreid: a few administrative things

Ralph: welcome a new WG member Kaleeg Hainsworth from BrightWing media

duga: ping questionnaire asks how we handle data, prevent unauth access, if we track ppl, how much user data we expose, how much metadata do we include
... many q's are not applicable to us as we have no APIs or protocols
... anyone who allows access to this data has to be careful re how it's exposed, but that's not a concern for our spec
... we could add a comment in our privacy section that says we could potentially id and track a user who has downloaded files
... we have a very limited set of data that's required, most of it is optional
... we will expose things about authors like their names but that's not extraordinary
... security implications of using json/html/css/jpegs/pngs but we don't have control over that

wendyreid: mattg and i added security + privacy considerations to audiobooks and pub-manifest specs

bigbluehat: i don't think author data is a privacy concern per se because it's on web pages and everywhere else - it's public info
... GDPR would not consider it private
... if and when we reintroduce discovery + apis, web publications and audio books could be used for private publications as well, but we're not close to that

duga: author name doesn't seem like it's PII but there is concern that any automated system used to create these could share that information and might reveal pennames

<JuanCorona> just got that the meeting ended

<George> We just lost audio on the dial in

duga: what should i do with these answers?

wendyreid: log as an issue on pub-manifest

we are joined by Christine Runnegar from Ping

<Ralph> [Christine Runnegar, representing PING, joins]

<wendyreid> https://github.com/w3c/pub-manifest/issues/61

wendyreid: we completed the self-review last week

duga: i reviewed pub-manifest and audiobook profile
... we are not defining an API or transmission protocol so there are not so many privacy and security issues
... most of the data in a publication is publicly available anyway
... we're fairly limited in the amt of data that we require in the files but we have a lot of optional info
... we don't allow for any user tracking
... info in our files will have been put there intentionally by the creator
... we use existing formats and protocols - jsonld/css/html - no diff from web as a whole - and we don't change any of the processing models
... you could ID users by the files they've downloaded but that's generally true - we don't expose a mechanism to reveal this info

<Zakim> bigbluehat, you wanted to explain "more secure" than the Web comment

bigbluehat: we don't have protocol so there are no concerns that come with HTTP or origins

Christine: we would love feedback about what made sense and what didn't
... privacy is not just concerned with what is private and what is public - it is concerned with info shared in one context being used in another context - so public info could still have privacy requirements
... dataset could be annotated with a note, e.g. "this dataset contains personal info"

duga: e.g. list of publications that a user has downloaded is extremely sensitive
... could also figure out who you are by what you've read
... however, we don't have a way of exposing this info

Christine: agree
... i would like to read your analysis of the security + privacy review and take a quick look at the spec, but it sounds like you're prepared

<Zakim> bigbluehat, you wanted to ask about context(s)

bigbluehat: i like context perspective rather than public/private
... e.g. what if i download someone's voicemails and package it as an audiobook
... no way to tell from the json file what is private or public
... we've relied on other layers to take care of privacy, on top of the data
... the data itself in the json file does not contain any info about privacy/security

Christine: generally what we've noticed in ping is that WGs may say that privacy is an implementation concern
... the problem is that there are good and bad implemens
... we shouldn't leave it up to the browsers et al to be the police

<Zakim> Ralph, you wanted to ask about "advice to users"

Ralph: q for Christine - what is the current advice to implementors
... what's the pref of the community for giving best practice advice

Christine: good question, don't want to speak for the community, but my preference would be to be as clear and direct as possible, and all WGs should strive to do the best that they can for privacy, so saying for implementors that you should do it this way to avoid risks
... researchers or govt people can police implementors
... how can you make privacy choices detectable?
... classic case is fingerprinting - no way to easily tell that a server is fingerprinting a user if it's passive
... active fingerprinting is at least detectable

<wendyreid> https://www.w3.org/TR/audiobooks/#security-privacy

<wendyreid> https://www.w3.org/TR/pub-manifest/#security-privacy

wendyreid: a content creator can put any info in any of the fields
... was hard to phrase this - we wanted to suggest that if you are going to be including identifiable info (name, url), you should get explicit approval where possible
... weren't sure if that suggestion oversteps our bounds

Christine: I'm very happy to ask the Ping group to take a look
... on the point of best practices, the WG may create a separate document
... other groups have done a group note document that covers what they'd like to see regarding this

duga: i don't like this idea that you should get explicit consent - we should not make this decision for people
... that's the role of laws

<Zakim> bigbluehat, you wanted to ask about parsing as the security vector--not content

bigbluehat: security tends to put it on the file format itself. in our situation, is the privacy vector on what you can record in the content
... you can't prevent someone from putting whatever they want in text plain
... are there privacy concerns around extensible formats like json-ld?
... we can prevent privacy infringing things but then we prevent many valid use cases
... e.g. a pub manifest that points to private data is a valid use case

<inserted> scribenick: Rachel

bigbluehat: You have to do something to the plain text file

scribe+

christine: I need clarification on the use cases

bigbluehat: audiobooks limits it to audio files but manifests hits a broader number of specs
... it can be created by hand or through an automated parser

christine: so you're capturing a bunch of information in a format. Anyone can put anything in it, even though it's designed for a publication purpose. I think you're right to draw a distinction. I hear duga in that laws have a role here.
... I think this has been very helpful for clarification
... I will take this analysis and wording back to PING

wendyreid: I am sending all the links etc via email

christine: in general, we want to be helpful - please share them. PING = W3C Privacy Interest Group. We want to improve privacy on the web

<Ralph> ᅜPrivacy Activity" (of which PING -- the Privacy Interest Group -- is a part)

Sync narration

marisa: Can I show off the work I did?
... moving highlight will not use CSS pseudoclasses
... according to daniel CSS4 is not mature enough so w've left room to grow
... also in room to grow is text selectors
... also in our list in one text and one audio in a parallel set

<marisa> https://raw.githack.com/w3c/sync-media-pub/master/samples/single-document/index.html

marisa: [demo]
... the text highlight synched with the audio and escapability allowed leaving the the reading which is important to accessibility

Makoto: is it possible to skip to different sections?

marisa: that would happen in the TOC which is out of scope for this demo

Makoto: do we need escapability?

marisa: We need it for structural elements

<bigbluehat> prior art from EPUB https://idpf.github.io/epub-vocabs/structure/

marisa: one of the issues we need to return to is how do we define what needs to be escapable
... the demo shows js implementation, playback including escapability and test feasbility
... we need to pick a mimetype

<Makoto> +q

Ralph: you need approval but its proceedural

marisa: I want an audiobook adjacent format

CharlesL: in terms of roles in json - could you have a type like table?

marisa: that's an open issue - we haven't defined what vocabulary has to be used
... another is incorporating into audiobooks

<Ralph> Sync Media issues list

Makoto: is this going to be applicable to any html document?

marisa: I would think so?

Makoto: do we need to coordinate with other groups then?

Ralph: yes - timed text is a good start

marisa: I shared with them our latest draft but they are interested in going in a different direction (sound effects).

<Zakim> wendyreid, you wanted to talk about duration

wendyreid: I will edit the duration and length issue

George: recently a discussion came up about alt text and we saw that some UAs allow for alt text to be read aloud
... we also are seeing skippability, the ability to avoid certain elements or collapse them

Avneesh: we should consider the use case for synch audio for alt text

marisa: this is an important oversight - we shouldn't say text but say element so to clarify that we are pointing to a media element

wendyreid: so if you are including supplemental content, publishers should be encouraged to do so as html

https://github.com/w3c/sync-media-pub/issues Sync Media issues list

CharlesL: in terms of personalization - if the source doc is changed how does that impact the rest of the functionality

laudrain: as publishers we like to not have to change the content much - in one of your issues you mention web annotation selectors
... is this something that can be chosen

bigbluehat: the current property is called text
... if the `text` property were changed to `fragment`, then this could work across various text-based formats such as `text/plain` and `text/csv` (etc). There's also interest from Google's Chrome team in bringing some of the Web Annotation style text selectors to HTML URLs, so there may be opportunity to provide more of those features to this spec too.

marisa: please submit a PR

bigbluehat: do your narration fils point to what they're narrating?

marisa: there's an open issue to allow for a url

<Zakim> romain, you wanted to ask about playback styling

<Makoto> +q

romain: the html spec says a new metadata name should not be created if the name is for something expected to have processing requirements.

marisa: I think we were putting this in the manifest

<Zakim> Ralph, you wanted to ask about re-use of audio files

marisa: can you open an issue

<Makoto> -q

bigbluehat: with tools like hypothesis they don't let you record audio but you can imagine it being added and creating a more verbose web annotation

marisa: open an issue?

Ralph: so if someone narrates a spec, which changes...

bigbluehat: web annotatotions give fall back selectors

<George> lost you folks again

marisa: I'm concerned that specifying where the anchoring takes place strays into best practices

George: when I'm reading with a screenreader it anounces the element
... if I'm escaping, it's helpful to know what I am escaping out of

marisa: we do have an open issue about role vocabulary - namely how strict it should be
... it's a user agent concern
... you need the user agents to recognize the roles and terms, etc
... it's an important issue

laudrain: to emphasize the pointer question - the use case of dyslexia to change the presentation of text with colored syllables
... this has a huge impact on the source text
... we would like to be able to do this in the same style as synch media

<Zakim> Ralph, you wanted to mention Personlization Semantics work https://www.w3.org/TR/2019/WD-personalization-semantics-1.0-20190711/

Ralph: there is a working group for personalization and accessibilities

bigbluehat: as of yet I don't know how to do a visualization without messing up the DOM
... the AOM tries to get there
... but you don't want to mess with the AOM
... that working group would be good to connect with on this front though

<Makoto> +q

marisa: it feels like a user agent space concern

Makoto: CSS inserts space characters
... I'm wondering if changing the spacing would impact what is being done

marisa: it depends on how fine grained the change is... Adding is likely less disruptive than subtracting

CharlesL: at word level it may get more complicated if you have additional spaces?

marisa: this is agnostic to the level at which you highlight

bigbluehat: DOM order is not important in synch media except to the author?

<Makoto> I am summoned by the I18N WG. Will be back.

marisa: I'm agnostic. footnotes will matter.

<George> I will catch up in the minutes about the meeting with Amazon Kindle folks.

<dauwhe> not yet. We are chair-free

<Avneesh> all of us are standing without the chair

<dauwhe> scribenick: dauwhe

wendyreid: plans have changed. we're not meeting with Amazon.
... I may be able to arrange a small-scale informal meeting on Thursday.
... this afternoon I'd like to tackle a few things... some open issues...
... and something that wasn't originally on the agenda. A while ago we had a strategy meeting for the publishing activity at w3c
... we can brainstorm about what we want to work on
... first we'll do open issues

<wendyreid> https://github.com/w3c/pub-manifest/issues/62

Issue #62

romain: it's an editorial issue
... some standards use a different terminology
... we talk about raising a warning when something fails
... but other specs use fail/error
... so we should adopt the terminology used elsewhere

wendyreid: we can talk about it with Matt later

<wendyreid> https://github.com/w3c/pub-manifest/issues/60

Issue #60

romain: there's something about if processing does not finish, the manifest is invalid
... and we don't say what we mean by valid

wendyreid: issue 60 regarding the handling of invalid values
... we say to issue warnings
... we should look more closely about what UAs should do in the case of these invalid values

<wendyreid> dauwhe: At the risk of sounding like a broken record, we should make it clear for user agents, and make it testable

<Zakim> bigbluehat, you wanted to note: tests or it isn't a feature

wendyreid: we should be specific... if a URL is invalid is different than if a date is invalid

bigbluehat: to go through pub process, we need tests
... which presumes testable things
... so if we're not clear enough we might not get out of CR

Ralph: we haven't required comprehensive test suites
... it's up to the WG
... but for vocab, we do want to show that each term is useful, and so it must be used by two implementations

laudrain: this brings back the q about audiobook check
... we have to figure out what to do with invalid values

<wendyreid> dauwhe: All the people I know working for reading systems deal with invalid EPUBs every day. I'm concerned about dealing with validation.

wendyreid: as one of the RS people, I deal with bad EPUBs every minute
... we create behaviours for certain common errors
... we can deal with RSC-011 :)
... certain errors like mimetype or missing files are critical failures, but we had to decide based on experience

<Zakim> bigbluehat, you wanted to ask about issue 60 specifically

wendyreid: technically we should not deal with a book with the RSC-011 but we feel we need to

bigbluehat: issue 60 isn't about testing, it's about things like forcing defaults or failing on processing
... we talk about internal representations
... are we now dealing with APIs and such?

wendyreid: we have to steer towards a data format
... and we still have a section on processing

bigbluehat: if we're json-LD, and we already have processing defined--it should choke on an invalid date

wendyreid: we could refer to JSON-LD

<wendyreid> https://github.com/w3c/pub-manifest/issues/51

Area 51

UNKNOWN_SPEAKER: additional values for RPD

wendyreid: do we need more values?

laurent: we have a framework, we have a property, we can extend when we want
... we know a future step will introduce visual narratives, but we don't need it yet

<wendyreid> dauwhe: In the future we should not discuss this without visual aids

wendyreid: laurent is right; we can defer to a manga profile

Ralph: this may be one place where the spec says we reserve all other values of this property for further work
... so implementations don't crash on values that may come along

<wendyreid> Proposed: Defer #51 in favour of the future BDCoMa Profile, but Publication Manifest should state that we reserve other values for future work.

<wendyreid> +1

<CharlesL> +1

<romain> +1

<duga> +1

<Rachel> +1

<JuanCorona> 0

<gpellegrino> 0

<garth> +1

<bigbluehat> +1

RESOLUTION: Defer #51 in favour of the future BDCoMa Profile, but Publication Manifest should state that we reserve other values for future work.

Issue #12

<wendyreid> https://github.com/w3c/pub-manifest/issues/12

wendyreid: this is my favorite issue!
... what if there's a null base URL?
... in light of recent changes to the specification, we have gotten rid of the canonicalization model algorithm
... so maybe this is a non-issue

bigbluehat: we don't know where these json files are used
... we don't have an origin now
... if LPF would be to go to REC, we might have to figure out how the base url is calculated
... but until this JSON file is related to some HTML document that can express a base URL, we don't need to say anything
... it's blank/null by default
... there are other concerns, but this issue is not an issue

<wendyreid> Proposed: Close Issue #12, the canonicalization algorithm has been removed, origin is no longer a concern for Publication Manifest

bigbluehat: before we vote
... the canonicalization thing has not been removed but renamed
... maybe leave that bit out
... just say it's a json data document thingy. might not be at a URL

Ralph: do you want to capture bigbluehat's thought that this will be a concern in the future when the manifest is is included in some future transfer protocol(s)

<wendyreid> Proposed: Close Issue #12, the canonicalization algorithm has been changed, origin is no longer a concern for Publication Manifest, but should be considered for specifications concerning discovery

<bigbluehat> +1

<wendyreid> +1

<laurent> +1

<gpellegrino> +1

<JuanCorona> +1

+1 with an error of 1

<duga> +1

<toshiakikoike> +1

<CharlesL> +1

RESOLUTION: Close Issue #12, the canonicalization algorithm has been changed, origin is no longer a concern for Publication Manifest, but should be considered for specifications concerning discovery

wendyreid: I think this one can be closed

<wendyreid> https://github.com/w3c/pub-manifest/issues/9

Issue number nine number nine number nine...

(wordplay not worthy of being minuted)

wendyreid: this is step 11 of the canonicalization algo
... there's not a base any more
... that step is gone
... so I think we can close

laurent: I agree with the resolution
... it's also true for LPF
... which is about something in a zip and says nothing about how it can be exposed on the web where it needs a URL

<wendyreid> Proposed: Close Issue #9, recent changes to the specification around the canonicalization algorithm mean there is no longer a base.

<garth> +1

<wendyreid> +1

<CharlesL> +1

<laurent> +1

<romain> +1

<bigbluehat> +1

<duga> +1

<toshiakikoike> +1

RESOLUTION: Close Issue #9, recent changes to the specification around the canonicalization algorithm mean there is no longer a base.

wendyreid: two issues in audiobooks
... one of them will spawn a new issue in pub manifest

<wendyreid> https://github.com/w3c/audiobooks/issues/12

Issue #12 in audiobooks

wendyreid: there was a suggestion to include 3 things
... abridged value
... preview
... how to include a preview
... and the last one, which will get a new issu
... e
... the isFamilyFriendly flag
... schema doesn't have a MPAA-type rating
... there isn't a standard
... the retailers tend to decide
... kobo ask publishers to identify, and then verify
... it depends on jurisdiction
... i think the flag is worth having
... it's a terrible name, but schema doesn't have a better one
... I'd like to close this issue, and then move the isFamilyFriendly to pub manifest

<wendyreid> Proposed: Close Audiobooks Issue #12, abridged and preview have been added to the specification, and isFamilyFriendly be moved to Publication Manifest

<duga> +1

<CharlesL> +1

<wendyreid> +1

<romain> +1

Rachel: when we say move to publication manifest, we're really just saying that we're going to open an issue

wendyreid: yes, just opening an issue

<garth> +1 (but don’t think we should do such a thing in pbu manifest, as I think it’s intractable)

RESOLUTION: Close Audiobooks Issue #12, abridged and preview have been added to the specification, and isFamilyFriendly be moved to Publication Manifest

<Rachel> +1

Plus one

Issue #22 in audiobooks

<wendyreid> https://github.com/w3c/audiobooks/issues/22

<Ralph> ["be moved to" as in "raised as an issue for discussion in"]

wendyreid: there's a mention of origin in the privacy and security section of audiobook
... (quoting from spec about where resources should be same-origin)

bigbluehat: given what we just said about pub manifest
... mentioning it here is confusing
... we should take it out, or talk about how to handle a manifest
... so we should just delete the line

wendyreid: I'm happy to delete

<wendyreid> Proposed: Close Audiobooks Issue #22, remove the line from the specification and defer to more qualified groups.

<bigbluehat> +1

<CharlesL> +1

<wendyreid> +1

<duga> +1

bigbluehat: i want to add that there's something we could call out
... that's the use of base in @context
... you can say there's a base of all the URLs in the JSON
... we could have a section that explains how to do that
... the advantage of @base in context is that your resource list uses fewer bytes

RESOLUTION: Close Audiobooks Issue #22, remove the line from the specification and defer to more qualified groups.

<wendyreid> ACTION: wendyreid to edit Audiobooks standard to remove line about the origin.

wendyreid: do want to discuss sync media

<Makoto> https://www.google.com/maps/dir/Hilton+Fukuoka+Sea+Hawk,+%EF%BC%92%E4%B8%81%E7%9B%AE-%EF%BC%92-%EF%BC%93+%E5%9C%B0%E8%A1%8C%E6%B5%9C+%E4%B8%AD%E5%A4%AE%E5%8C%BA+Fukuoka,+%E7%A6%8F%E5%B2%A1%E7%9C%8C/''/@33.5877455,130.3494776,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x35419252ad90b435:0x3bb689fc8164a932!2m2!1d130.3597275!2d33.5945018!1m5!1m1!1s0x354193a481c0dac3:0xb341cf51ede86847!2m2!1d130.357555!2d33.581152!3e2

Fragmentions

marisa: a way to non-desctructively reference text in an html doc

<Makoto> The above URL shows the location of the restaurant for our dinner.

<duga> scribe+

<Makoto> 24 minutes by foot from here.

<duga> marisa: Can talk DOM events

<duga> ... Are these standard events?

<duga> romain: Yes, there are some standard ones

<duga> ... it is easy to polyfill

<duga> bigbluehat: Back to fragmention thing

<duga> ... related to the Google thing mentioned earlier

<duga> ... fragmention is only JS, will never be in a standard

<duga> ... The other one is designed to be a broken URL

<duga> marisa: Wants bigbluehat and Tantek in the same room to duke it out

<duga> ... Personally, neutral on the options

<duga> bigbluehat: If you keep with single string fragment identifier, only a few are refertenceable from a spec

<duga> ... For HTML probably want the Chrome thing

<Makoto> <dinner>The current list of participants shows 17 attendees.</dinner>

<duga> ... Will only show up in the scrollto section, may have spec ramifications

<duga> marisa: Double hash anchors is the previous style

<duga> bigbluehat: Big things is want somethign you can reference

<duga> marisa: I am just a note, I will never be a rec

<Makoto> <dinner>If you forgot to add yourself to the list, contact me right now. Otherwise, even if you go there, you will have no food.

<duga> marisa: Are there and standard DOM events that would apply

<romain> known interfaces based on Event https://developer.mozilla.org/en-US/docs/Web/API/Event#Introduction

<duga> ... then our own special ones like onCanEscape

<duga> ... what are the standard playback DOM events

<duga> ... ?

<duga> romain: Posted a link

<duga> JuanCorona: What about a media event?

<duga> ... are you looking for anything that sounds remotely like it?

<duga> marisa: Just don't want to reinvent

<duga> JuanCorona: What are the events for an audio or video element?

<Ralph> Media events [MDN] -- might be relevant

<duga> romain: I don't we need start or stop events

<duga> ... Mostly created for the playback moving thing

<duga> ... so there would be an event for when the element changes

<JuanCorona> https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play_event

<duga> ... Playback of page showing highlight moving, and could add a magnification to show the currently spoken text

<duga> marisa: Could add that to the demo

<duga> ... In what part of the spec do we define DOM events?

<duga> ... A lot of it could beyond playback (eg page change events)

<Makoto> <dinner>JuanCorona, I suppose that you are not coming.</dinner>

<duga> dauwhe: Did Brady talk about this years ago?

<duga> duga: Not exactly, that was layout

<duga> marisa: We define an event, polyfill it, an enabled page would detect that and do something cool

<marisa> https://github.com/w3c/sync-media-pub/issues/15

<duga> marisa: Any takers for issue 15?

<duga> ... Where do you make the association?

<duga> ... We don't know how a pub manifest will be processed

<duga> bigbluehat: Would leave it out

<duga> marisa: No, needs to be in pub manifest for audiobooks

<duga> bigbluehat: Oh

<duga> marisa: HTML pub manifest doesn't really exist yet

<duga> ... So it is really hard to solve, and we keep going in circles

<duga> bigbluehat: Sync media is html only?

<duga> marisa: No, can be an mp3

<duga> bigbluehat: The demo was text centric, in audiobooks it is opposite

<duga> marisa: Yeah, but the user experience could still be indentical

<duga> bigbluehat: Can you get the same result using the TOC with sync media?

<duga> marisa: No, don't want sync media on TOC

<duga> general agreement

<duga> bigbluehat: Index file that comes with audiobooks is just a landing page, right?

<duga> marisa: Could be, would have to check

<Makoto> <dinner>Will Ivan attend the dinner? Is he here in Fukuoka?</dinner>

<duga> marisa: Do we require it in the html head always for consistency? Or leave it optional?

<duga> ... Don't know, don't feel strongly, but need to decide

<Makoto> <dinner>Wendy, thanks.</dinner>

<duga> ... moving on ...

<duga> ... Format the explainer

<duga> ... Needs to look like an explainer. Could use some editing help.

<marisa> https://github.com/w3c/sync-media-pub/issues/13

<duga> Rachel: I can help

<duga> marisa: Next issue, 13

<duga> ... Want to leave this not strict

<duga> ... Doesn't even have to be the word role

<duga> bigbluehat: Are you referencing an existing vocab?

<duga> marisa: No, that is a minefield

<duga> ... Maybe using "role" itself is dangerous

<duga> ... Any complicated structure you might want to escape, or anything you might want to skip

<duga> ... skipability might be ignore page numbers

<duga> romain: The issue of not having a finite list, it enters the UX realm

<duga> ... Need translations etc

<duga> ... if it is set, then the UA knows what roles to expose

<duga> marisa: In epub, finding the right set of terms was hard, eg how extensible should they be?

<duga> ... Like language tags, don't be too rigid

<duga> laudrain: What about the term skippable?

<duga> marisa: But how will they know what I am skipping?

<duga> ... eg need to say skip page numbers, but not footnotes

<duga> ... for escaping it is easy

<duga> dauwhe: It is also a little about how you are presenting the audio to the user

<duga> ... There was an abandoned attempt in CSS to do that

<duga> marisa: Please join the list!

<wendyreid> duga: You need to know why its skippable, can you give it a reason instead of a role

<wendyreid> marisa: You'd run into translation problems, but the term doesn't need to have meaning outside of the scope

<duga> laudrain: Reminds me of discussion around "purpose"

<duga> CharlesL: Purpose could be reused

<duga> laudrain: Where is the discussion on that?

<duga> CharlesL: Have gone sideways from there

<bigbluehat> https://www.w3.org/TR/annotation-model/#motivation-and-purpose

<duga> bigbluehat: Web annotations has purpose and motivations already

<duga> ... "this is why I am pointing at something"

<duga> ... synced media could say "these are the terms we are using"

<duga> marisa: Yeah, that's what we need to figure out

<marisa> https://github.com/w3c/sync-media-pub/issues/12

<duga> bigbluehat: Could steal from the existing work

<duga> wendyreid: Let's break

<CharlesL> scribe+

<CharlesL> Wendy: strategy meeting, what to work on, ideas, talk business, communities etc. on what the future would hold. Charter expires next year… we can create a new charter and do new things. could be brought to us from others but we can suggest new ideas for future work.

<CharlesL> … ideas for next strategy meeting, so what should we include

<CharlesL> … could be big ideas

<CharlesL> bigbluehat: open to ideas around web components that could become publications, iframe needs, reinvented transclusion element (toast / switch) web components show them off get developer demand then put them into HTML maybe…

<CharlesL> … could get stuck in JS. early experiments 2 years ago single HTML document and transcluding them singularly styled included. Virtual scroll (web component / standard web component potentially)

<CharlesL> …, I would like to revisit this, maybe polyfils can also be valid implementation.

<CharlesL> dauwhe: incubation / experimentation this group may not be the place to do this. this group to take existing proving things and bring them to the finish.

<CharlesL> Rachel: roadmaps to the future this work should be distributed. escalate items from CG to WG

<CharlesL> BigBlueHat: how to liaison these efforts , would be nice to write a proper spec, but we are not the implementers. what are the large needs when the browsers come into the room that we have a good collective set of deliverables that we need.

<CharlesL> JuanCorona: Likes Marisa's work, will the WG support this work like we saw with the sync media demo

<CharlesL> wendyreid: there is a SyncMedia CG is also is related in the publication manifest and audiobooks. publishing CG EPUB3 CG there is room for that.

<CharlesL> … depends on how vocal and very specific requirement for us, and the WG has to handle bigger issue of how we handle bringing books to the web.

<CharlesL> romain: can Publishing WG can do horizontal reviews in a publishing context. dont have a spec for this but a lot of groups are interest in us Web Components, CSS etc.

<CharlesL> Avneesh: Where do we want to go, these are all ways of getting there but what is the ultimate goal. Do we have any strong business cases.

<CharlesL> Rachel: we need to consider epub3.2 needs to move from Final specification to a Rec Track which would move from CG to WG.

<duga> +1 Rachel

<CharlesL> laurent: we need new standards to do more types of publications. I am against having EPUB as a recomendation;

<CharlesL> … CPU on reading devices are getting faster better etc. but we can infuse new capabilities for the web, use incubation in community groups to foster this experimentation etc. and see what we can take further in the WG.

<JuanCorona> +1 laudrain, on large DOM ideas

<CharlesL> … new standards personalization for renderings new ways to display info without changing it. new work on JSONLD an metadata. standard packaging format CSS issues still for rendering content. we need to have more effort in publishing companies EDRLab to enable more work in CSS rendering for publications. Horizontal Accessibility etc.

<CharlesL> wendyreid: ProRectrack for EPUB3.2. incubation is important (web publications we didn't have incubation and proof that it would work.)

<CharlesL> … which is why we didn't have this incubation and is why we decided to go in the direction we did. But with EPUB we have 20 years of incubation and know what we will get. We can then go to these issues to other groups if we are moving this to publication. for CSS, packaging etc.

<CharlesL> … we know what the problems are and what the business needs and they are not ready to move away from EPUB. I think we can move EPUB to rec, track and can web publishing, scholarly publishing, newspapers etc we can work with them.

<CharlesL> dauwhe: EPUB and large documents we don't require chunking but went that way due to limitations of a sony reader at the time.

<CharlesL> … abstain from EPUB rec track.

<CharlesL> kaleeg: I have been making EPUBs for over 20 years. Publishing WG is critical for me to look for W3C specs. Humanity in this world, I think we have the opportunity to take the publication (web;book sites) to take their own place in the world and a different kind of publishing model

<CharlesL> … we have the opportunity to create our own space and new publishing model

<CharlesL> … we can reach out and expand in populations across the planet.

<inserted> This future that you describe sounds exciting and the incubation that will take place in the community groups sounds as though it will be fun to participate in but what is the standard that we use with user agents, browsers, and others now? We have a carefully incubated and

<CharlesL> Rachel: Dave mention that he splits books into separate files but we must split them because large textbooks has to be split or they can't be loaded on these reading systems.

<CharlesL> duga: you can't change the world by writing a spec, but if no one asks for it it won't matter ,but people are asking for an EPUB spec.

<Makoto_> +q

<CharlesL> … I don't want to work on things unless there are more than 2 parties that are interested.

<CharlesL> Ralph: EPUB3 recommendation: better EPUB/PDF if there is enough interest we can do both. we shouldn't obsess over whether which to do as if we must choose only one thing to work on. for web to get better that Dave and others to force CSS to improve and the quickest way to do this for EPUB3.3 (rec track) or we should do something further reaching.

<CharlesL> … we should be doing more horizontal review this group has more experience and continue telling CSS to do that.

<Makoto_> <dinner>We have to leave here around 19:30.</dinner>

<CharlesL> … it will be a lot of work as Dave points out,

<Makoto_> <dinner>If we are late, our seats might be cancelled.</dinner>

<CharlesL> … lets figure out Ebooks work on the web. whats better than PDF, but we have to do better.

<Rachel> negotiated for consensus document that is ready to go to forward to the PWG and benefit a broader audience./

<CharlesL> … lets use the talents to get that. not to the exclusion of EPUB3

<CharlesL> dauwhe: there are lots of things we can do we can make EPUB better, its a 1 billion dollar industry. 10 years from now there will be a lot of EPUB still around.

<CharlesL> kaleeg:

<CharlesL> … EPUB specs not changing the world, it changed my world a w3c spec in that I have seen the w3c spec/reports specs like decloration and when I read some specs reports and the publishing WG and I saw the possibility of an EPUB could be a a 10 billion dollar industry.

<CharlesL> … new future is possible and new directions ahead our world changing every year a new million people gain access to the web.

<CharlesL> … w3c has that guiding light.

<CharlesL> wendyreid: we have the capacity / knowledge we can bring EPUB to recomendation… and there is a growing number of folks publishing on the web main stream publishing with massive (fanFiction) communities already doing this

<CharlesL> … having trouble tagging their content, apply metadata

<CharlesL> … we know how self publishers do it, why are they doing it on the web, and not using EPUB.

<CharlesL> … we need to reach out to this community, publishing we mean trade books but thats not the only publishing we are talking about.

<CharlesL> Makoto_: proceedure: we are deviating the w3c process. steering committee when IDPF was absolved in W3C. we need some changes, either we give up or we ask w3c team/committee.

<CharlesL> 3.2 as a w3c rec is not possible without changes to the process.

<CharlesL> … we can not remove these backward compatability.

<CharlesL> … we are expecting a new charter if Browser vendors are involved and part of the steering committee.

<CharlesL> Avneesh: 2/3 steps after this would be great. energy on this group is low. we need a strong business case. or exciting reason to move fwd. maybe within the w3c

<CharlesL> … explore within w3c maybe see web publishing working or a strong vision to get our members excited. we need to do something different.

<CharlesL> laurent: EPUB3 as a rec. do we expect more publications as a result in these communities which are not currently using EPUB now?

<CharlesL> … better document maybe interoperability , technical difficulties due to CSS etc.

<Makoto_> +q

<CharlesL> wendyreid: EPUB stronger epub light reader how can we open EPUB in a browser. better closer to the web,improving html for rendering, css there is potential there.

<CharlesL> … a billion dollar industry lets make it easier for them more understandable for reading systems, closer to the web.

<Makoto_> Three cheers to Dave

<CharlesL> dauwhe: as editor of EPUB right now I want to rewrite every word especially with Reading system conformance its difficult for everyone involved… I will do this regardless of rectrack.

<CharlesL> … there are a lot of problems on how things are organized, how we are going to work on it and what we are going to work on and the relationship between steering and WG and business group and the WG this has created difficulties between the WG/CG and BG. need clearer responsibilities and much of this is outside process there are gaps in these.

<romain> (dauwhe just covered what q+'ed for: a full rewrite w/b needed, it doesn't necessarily have to happen in a WG)

<CharlesL> wendyreid: should not talk about process stuff for us

<CharlesL> Ralph: Makoto and Dave talked about that this as a bug, but they perhaps should consider it as a feature, this community is trying to push web technology that hasn't been pushed this way before. experiment to enhance web technologies.

<CharlesL> … w3c needs more direction from the business models and direct more of the technical work from a business perspective.

<CharlesL> … lets keep those conversations separate

<CharlesL> … Makoto sayid"W3C specs are not concerned about Longevity" we do care about the content existed.

<CharlesL> … 0.001 feature is important "you" get to decide what is important. the whole community reviews our work, Our work will be reviewed and commented on

<CharlesL> Luc: EPUB as a rec, why we failed with Web publications and how it will be better if we work on EPUB3 as a rec.

<CharlesL> wendyreid: End of Day 1!

- DRAFT -

Publishing Working Group F2F in Fukuoka — First day

16 Sep 2019

Attendees

Contents

lightweight packaging format

horizontal reviews

Sync narration

Issue #62

Issue #60

Area 51

Issue #12

Issue number nine number nine number nine...

Issue #12 in audiobooks

Issue #22 in audiobooks

Fragmentions

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output