Re: [dpub-loc] Draft update

> What really is important is the operative aspect, ie, that M is made available to the Processor
>
Agreed, as I said in my first sentence below.

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Friday, February 12, 2016 at 9:55 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 13:04, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

On Possible answer to question #1

I agree with the key statement: responding to that URL MUST make M available to the processor.   And I agree that there could be many ways to achieve it such that the processor must be prepared to handle multiple possible returns and/or be able to request the specific form of the response.

However, where I think we differ is whether the return value is determined by S or by the Processor (or some combination of the two).

I would think that the most common implementation would be that the PWP processor specify the requested content-type as part of the GET request via the Accept headers (<https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1>).   Based on that header, S will return one of the four suggested return types (or possibly something else, if it can match the header in some other way).  If it cannot, then it returns 406 as spec’d.

The advantage to this approach – other than it is completely consistent with standard REST behavior – is that it doesn’t require any configuration of S. An “out of the box” S would return whatever is available at the URL and all other options would not be supported – thus putting all the burden on the Processor to be able to handle it.   However, if you have a smart/configured S, then it can help out Processors by supporting more options.


I am not sure I understand your issue: this is one of the alternatives I describe at the very end, essentially describing content negotiations. And, actually… I agree that this may be one of the most useful setup for S. But, as I tried to emphasize, I do not believe it is in the scope of PWP to prescribe those. What really is important is the operative aspect, ie, that M is made available to the Processor.

Ivan






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