See also: IRC log
<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.
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]