Re: [dpub-loc] Draft update

Hi Ben,

Thanks for this. I removed the minor mistakes in my response below (to save space), I just implemented those.


> On 12 Feb 2016, at 10:13, Ben De Meester <ben.demeester@ugent.be> wrote:
> 
> Hi Ivan, all,
<snip>

> 
> _Also, I think we agreed that **L** doesn't have to be different than **Lu**, maybe we should keep that documented here as well._
> 

Right, I have added a remark in the document. But I think for the example it is better to make them radically different to avoid making it dependent of this.


> Line 32
> > * **M** contains a reference to **L**, and **M** is also available in all the different states of **P**.
> 
> _This would mean that all different states of **P** have references to **Lp** and **Lu**, right? I would lessen the constraint:_
> 
> * **M** contains a reference to **L**, and **L** is also available in all the different states of **P**.
> 
> _Given your possible answer on Q1, you can get to **M** via **L**, and thus a connection can then be made between the different states of **P** via **M**, so this change would not introduce conflicts_

I would prefer to keep the stronger constraint for now. This indeed means that all the various states include exactly the same manifest/metadata. This may backfire at some point, and we may have to come back on this for practical reasons but for maintenance's sake I believe this is really more safe.

<snip>
> 
> Line 60
> >    * If the preferred state is the packed one, then **Lp** accessed, unpacked, and the image is localized within the unpacked content (and that usually means using the relative URL as some sort of a file system path within that unpacked content)
> 
> _To be clear, this means the PWP on **Lp** is downloaded entirely and the image is retrieved client-side, right? I agree that this is a viable solution, with minimal server requirements. But if your server is smarter, it can retrieve that image client-side and return that image directly. Do we need to fix that functionality as either client-side or server-side? Can't we just define functionalities and let implementers implement as they see fit? Or is that just crazy talk? :)_

it is not crazy talk at all, but I do not think it is something we want to fix now. These are optimizations of the client implementation, not a conceptual requirement. I have added a parenthetical statement in the document for now.

Thanks again Ben!

Ivan

----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704