Re: [dpub-loc] Draft update

As addressed in Q1 – M comes from the request for the PWP (either via Lp, Lu or the Canonical URL (Lc?)).  Once the PWP has M, then it has all the information it needs (we assume!) to be able to get all the resources from S.

I don't think we need to add anything else – do you?

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Friday, February 12, 2016 at 9:54 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpub-loc] Draft update


On 12 Feb 2016, at 12:51, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

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.

Hm. You are right, that may be a bit more complicated.


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


We still have to describe somewhere where the information comes from. The scheme I have in my head right now is as follows (but I have not yet added to the text): the final M, as a set of metadata statements, may come from different sources, and it is up to the PWP Processor to combine them. The requirement is that the Processor should get all the various metadata pieces, and how this is done is up to S.

One way is the usage of the Link header (described in the document) which would then be considered as, possibly, an extra set of metadata statements added to the metadata embedded in a packed publication. Ie, the content of P remains unchanged as far as the publisher goes (ie, it does not have to unpack the document, add the values of Lu and Lp to the embedded metadata) but the metadata delivered to the processor is still the complete M.

WDYT?

Ivan


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







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