See also: IRC log
<lrosenth> testing
<bjdmeest> scribenick: bjdmeest
<scribe> scribenick: rdeltour
<bjdmeest> https://github.com/w3c/dpub-pwp-loc/issues/22
ben: this is about manifest retrieval from the package. For now there is a note.
ivan: right. I think we can close it.
ben: OK, issue close.
<bjdmeest> https://github.com/w3c/dpub-pwp-loc/issues/9
ben: we shouldn't make things more
complicated than they are.
... maybe we can just remove that section.
ivan: I agree
leanard: right, just remove it
ben: ok great, let's close this.
ivan: ben, will you take care of the editing?
ben: yes
ben: we identified some issues, haven't put
them on github yet
... romain, I can go through the minutes and just add them to the github
tracker?
<bjdmeest> scribenick: bjdmeest
rdeltour: some discussion, not yet clearly
defined
... maybe we can define them within our group?
ivan: this group could contribute to that
effort
... of the general pwp issues
rdeltour: there is some overlap, e.g., the ones from leonard and nick
ivan: if there are overlaps, I don't think
that is a problem
... several use cases that lead to similar requirements, re-enforces
those requirements
rdeltour: in terms of process: ben, you can
go over the minutes and aggregate all mentioned use cases in one
document
... to the mailing list or as a new issue
ivan: issue tracker might be better
rdeltour: maybe all current use cases can
be merged into one bigger ues case
... that's up to you
... we can possibly merge smaller use cases into bigger ones
ivan: if you can try to abstract the use cases from the previous discussion, then that would be a big help
<bjdmeest> http://w3c.github.io/dpub-pwp-loc/#breadcrumbs
leonard: interesting idea, but it makes an
assumption that you can change a PWP
... in the first case (teacher adding annotations) there is potentially
changes to the PWP
... inside of what we consider the PWP
... I think we have to assume that we can't, that a PWP is unmodifiable
... everything needs to be done externally
ivan: I think it's not an assumption
... I agree that there are cases when this is not impossible
... there is a possibility that the manifest itself is outside the PWP
... there has to be a note that the mechanism relies on the fact that
the manifest can be modified
leonard: yes
ben: I was wondering if we had to limit this to the fact that the PWP shouldn't be changed
ivan: you don't change a PWP, you create a new
leonard: but it's predicated on the fact
that you have the right to do that
... but really you only need to modfiy the manifest without touching the
PWP
ben: for instance a publishers create a PWP
with embedded video and you want to modify this PWP to reference to
youtube video
... you create a new PWP but maintain the breadcrumbs
ivan: I think we all agree here
ben: ok
ivan: if we don't have anything left on the
agenda I'd like to discuss something
... at some point we should discuss how we see the evolution of this
document
... I have the impression we're close to an end.
... it's not clear to my mind what to do with this document when it's
finalized
... we have 3 interrelated documents: PWP, UC&R, locators
... I'd like to head how do you see that
... that may lead to editorial work
leonard: I agree that at some point we have to figure out that problem
ivan: should I share my views?
leonard: yes
ivan: my feeling is that we should converge
to have 2 docs, one is the UC doc and the other is PWP
... on the long term
... that means that you should take over the use cases part of PWP into
the UC document
... then the PWP doc becomes a more technical document
... includes what we did for locators
... and the section we have on SW (reworded to make it more agnostic)
leonard: makes sense
romain: I like the approach
ivan: when you and Heather start editing the UC doc, we have to start working on ripping off the PWP document
leonard: maybe bring the discussion to the larger group?
ivan: ben you'll probably be asked to
summarize our TF work to the larger group, we should propose it at this
time.
... if the locators work is "done", the next big thing is to look at
what is the manifest and what information is needed there
leonard: I do agree on that
... but I'm wondering how we address the manifest without addressing the
package issue.
... but otherwise I do agree that the next big thing is the manifest