W3C

- DRAFT -

DPUB Telco

11 Jul 2016

Agenda

See also: IRC log

Attendees

Present
Tzviya, George, HeatherFlanagan, Avneesh, Chris_Maden, astearns, Peter, Krautzberger, duga, Benjamin_Young, dauwhe, Charles_LaPierre, garth, Luc, rdeltour, GeorgeK, Bill_Kasdorf, Ben_De_Meester
Regrets
Markus, Ivan, Nick_Ruffilo, Baldur, dkaplan, Nick_Barreto
Chair
Tzviya
Scribe
pkra

Contents


<tzviya> scribenick: pkra

<HeatherF> federated identity ftw!

<HeatherF> dauwhe, do you have birds in your house?

tzviya: approval of minutes of last meeting and F2F meeting.

<tzviya> https://www.w3.org/2016/06/27-DPUB-minutes.html

tzviya: minutes are approved.

<tzviya> http://www.w3.org/2016/07/07-dpub-minutes.html

tzviya: F2F minutes are also approved.

not me :(

:)

scribe: we have some new members!
... garth!

garth: Garth Conboy. Chairman of board IDPF, doing epub since before epub was a thing.

tzviya: NOTE: no other meetings in July.
... work on use cases or take a vacation!

<garth> should be muted now (Brady and I are on the same bus)

<tzviya> http://w3c.github.io/dpub-pwp-ucr/#manifests-and-packages

tzviya: we'll continue live editing the use cases (see google doc)

<tzviya> https://docs.google.com/document/d/1m8EnN5yxHGPjLr497gSrPSJrRKIjMZBIzSpbHKhCHAw/edit?usp=sharing

tzviya: we'll be working on manifests and packages today -- see github and google doc links above
... last week, finished Sect 2.
... some use case fairly build out, others very limited (from brainstorming)
... we need to work them out.
... make them meaningful, also beyond publishing
... first example: streamlined access to components.
... suggestion: let's jump to 5.4.
... "As a reading system, I need to know if support for media type included in the publication."

let's re-word this.

<garth> Does the publication what to know about RS capabilities, or the RS want to know about the publication?

garth: Does the publication what to know about RS capabilities, or the RS want to know about the publication?

tzviya: this is primarily about the publication not the reading system.

dauwhe: we need to motivate this more. Naive person might say "it's all in the HTML!".
... this historical requirement that the reading system has to have a lot of information without parsing the entire document.

tzviya: does it belong here?

dauwhe: probably yes since this is the information that the reading system has to digest.

tzviya: [lots of live editing on the google doc]
... general req statement: "A user agent requires information about the package and its components in order to process it."
... then specialized "As a reading system, I need to know if a publication contains/requires support for a specified media type (without processing all content documents)."
... does that work?

dauwhe: +1

tzviya: next: "As a reading system, I need descriptions about the publication that travel with the publication whether online or offline. For example: author(s), title, size, rights and permissions, accessibility, multimedia details."
... let's unpack.
... this is merging the concept of manifest and metadata somewhat.
... we talk about media type. Do we want to mention file size?

heatherF: +1

tzviya: should we mention why file size might be a problem?
... "I cannot process files of certain size b/c ..."

heather: "connection speed, storage"

George: "response time"

laudrain: memory limitation

heatherF: why would a reading system care about author and title? (as opposed to file size)

George: e.g., "reading systems needs to display the available packages in a certain author"

<hughmcguire> yes!

tzviya: true but that's more a display than a processing problem..
... next: rights and permissions
... if linked data (ideal world), then falls into processing.

HeatherF: discussion about it last week (F2F?)

tzviya: but last week was more about DRM.

Bill_Kasdorf: add "at a component level" as they might differ?

tzviya: the section is about "package and its components". Does that suffice?

Bill_Kasdorf: yes.

dauwhe: touches on another item. The collection of objects that make up the publication. We need to talk about that as a whole as well.
... we want to make some of these assumptions clear.

tzivya: "each component identified in the manifest"?

dauwhe: we had lots of discussions and one reason is that we need to have information on the whole.
... e.g., if you have three html files, there's no natural point where to put information on the whole.

Bill_Kasdorf: agreed. Not specific to rights&permissions.

tzivya: in general section, we have "package needs to be processed as a whole"

George: browser typically ignore that which they don't understand.
... in our case, use agent needs to learn early on what parts of the whole it cannot process.
... or present.

tzviya: "a publication represents a unit compromises of several components. There must be a structure that identifies the components of the package."
... does that work?

dauwhe: avoiding the word "spine" we need to know what comes next.

that was me. can't edit as fast :)

tzivya: "A publication represents a unit comprised of several components. There must be a structure that identifies the components of the unit that describes the constituents and relationships between them."
... what does the manifest need to accomplish?
... e.g., media type. what does it do for the user agent?

dauwhe: tells UA that there's something it can/cannot present.
... e.g., video on a device that cannot do video.

tzviya: "A User Agent requires about media-type for each component so that it can understand whether information can be conveyed to the user the reader without parsing through the contents." Does that make sense?

HeatherF: good but thinking about how it works with examples in Sec2

tzviya: doesn't have to match precisely.
... "A User Agent must know the component parts of a publication such that it can be made available for offline use." Could someone elaborate?

garth: the offline use case.

dauwhe: e.g., using a serviceworker, I need to tell it what to cache.

tzviya: file size, rights&perms, a11y -- do we want that in the manifest statement?
... or do we need something else?
... dauwhe you talked about relationship between files (e.g. reading order)
... let's put this in context of manifest.

dauwhe: it should be possible to describe the sequence of which components should be presented to the user first.

tzviya: "A User Agent must know which component of the PWP to present to the user first."

<astearns> The media-type stuff makes sense, and I'm sympathetic to the notion that a reading system should notify the user when there's content it can't render. But I'm wondering whether this goes too far afield from how the web works. Why not use the same affordances browsers have with broken video or images, and leave it at that?

???: should it not be in order?

tzivya: I think those are two different use cases. Someone from WebApps talked about startURL.

dauwhe: e.g., choose your adventure.

tzivya: "A User Agent must know in what sequence to present components to users."

(multi-user reading experience FTW)

tzivya: anything else?

Bill_Kasdorf: should we mention which components are fundamental?

tzviya: already in the fundamentals.

dauwhe: might have to link. Manifest might describe a lot of the aspects of a publication.
... we probably shouldn't worry about duplication at this time.

Bill_Kasdorf: just seemed logical. "What should be presented first, in which order" naturally leads to "which are essential"
... "A User Agent must know which components are essential to the publication."

tzivya: we decided against "essential".

Bill_Kasdorf: right. What do we use?

tzviya: link to Section 2.1.xx

dauwhe: and then we ignore who gets to decide this.

tzivya: we decided it can be situational. E.g., dyslexic font.
... which is user required. Others (legally required fonts) might be author required.
... let's clean up the following part.
... thanks for the additional edits.
... so we have info on media type, size, permissions&rights, accessibility.

<garth> FWIW -- coming up to fade-out portion of bus ride -- It's been an initial pleasure!

Hugh: could you clarify performance and memory limitation?

dauwhe: e.g. I have 500MB of images and documents. Would I rather parse them all or have a json list?
... or e.g., efficiency.
... or e.g. efficiency.

garth: also driven by offline use case.

tzivya: do we want to mention "pre-processor" anywhre?
... e.g., "before displaying it." to "without pre-processing"?

dauwhe: seems odd but no real insight into what reading systems do.

luc: e.g., reading system preloads next chapter before it is accessed.

tzviya: let's do "how to present content before displaying it or pre-processing."
... biblio use case (publication information) -- please use the break to add.
... what about "As a reading system, I need to know if I need additional processing instructions, such as with MathML."?

dauwhe: example for general principle. If a section includes MathML, the system might have to load MathJax etc.

tzviya: all clear.
... next up: "As a reading system, I should be able to process permissions and rights information for each component identified in the package. "

luc: we had this in the other section?

tzivya: here about placing content in package for offline
... "For example, I need to know if I have the rights to place an image of the Mona Lisa owned by Louvre in a package to be downloaded offline."
... next: offline use case.
... is it delivered to user agent or to user?

available?

scribe: I'll just delete it for now. Any objections?
... what we haven't done today is anything to bibliographic metadata, editing/updating the manifest.
... given our hiatus, we need to finish this soon. We want this at TPAC and we don't have a lot of time once we get back to it in August.
... so if you have time, please focus on this.

laudrain: if there an agenda for TPAC?

tzviya: not yet.

Bill_Kasdorf: all day sessions in Mon/Tue?

tzviya: yes.

dauwhe: book now -- hotels filling up.

<HeatherF> Thanks! I'll have this updated on git in a few minutes.

tzivya: thanks everyone.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/07/11 16:00:11 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/link to Section .../link to Section 2.1.xx/
Found ScribeNick: pkra
Inferring Scribes: pkra

WARNING: No "Topic:" lines found.

Present: Tzviya George HeatherFlanagan Avneesh Chris_Maden astearns Peter Krautzberger duga Benjamin_Young dauwhe Charles_LaPierre garth Luc rdeltour GeorgeK Bill_Kasdorf Ben_De_Meester
Regrets: Markus Ivan Nick_Ruffilo Baldur dkaplan Nick_Barreto
Agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Jul/0018.html
Got date from IRC log name: 11 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/11-dpub-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]