Re: [dpub-loc] Draft update

On Possible answer to Q2.

I can’t agree to the first half of assumption #2.  It would imply that M is created AFTER P is already placed on the server (or is authored by the same system that is responsible for hosting P on S). And if M is modified after P is created, then P isn’t actually P, but instead is P’ - which might be fine for the purposes of publishing, but we need to be clear about that.

But I completely agree with the second half – that the PWP Processor knows Lp and Lu.  However, it doesn’t get that entirely from M, but from additional material available on S (or local to the PWP Processor).

And therefore, the answers for Q2 as stated still apply since in neither cases is the bit about M and S relevant.

So just remove that bit about M knowing S and we’re good…

Leonard

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Friday, February 12, 2016 at 5:44 AM
To: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpub-loc] Draft update
Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Resent-Date: Fri, 12 Feb 2016 10:44:58 +0000

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<mailto: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