W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2016

Re: [dpub-loc] Draft update

From: Ivan Herman <ivan@w3.org>
Date: Fri, 12 Feb 2016 11:44:46 +0100
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <AD142D8B-6FEF-4E18-BE77-FA744E3793EF@w3.org>
To: Ben De Meester <ben.demeester@ugent.be>
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,

> _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.

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

Received on Friday, 12 February 2016 10:44:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:25 UTC