Re: [dpub-loc] New version of the PWP Client processor diagrams

> On 3 Mar 2016, at 18:43, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> ResultType->Package->Unpack package, retrieve M1->M2.   How do I get from M1->M2??

Ah, sorry, you are right, that is a bug. That should retrieve M2. Will take care of this tomorrow.

Thanks!

Ivan

> 
> As long as it’s a concept and not a specific implementation – that’s fine – I can live with the embed section on the graphic.
> 
> Thanks for reminding me on M1,1 and M3 – you are absolutely right!
> 
> 
> 
> From: Ivan Herman <ivan@w3.org>
> Date: Thursday, March 3, 2016 at 10:57 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
> Subject: Re: [dpub-loc] New version of the PWP Client processor diagrams
> 
> 
>> On 3 Mar 2016, at 15:51, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> 
>> First, simple change.  On the package being returned, it shouldn’t be M1 since it then goes to M2 and it’s not clear what the difference is.  Just make that M2, since it’s no different than the manifest directly case.
> 
> Isn't it what it says? The box says M2 = M1,0 + M1,1
> 
> 
>> 
>> Apparently, however, I missed a conversation about how the manifest might come “inline” some returned HTML.   Can someone explain the use cases for this and when this would be used (or even useful)?   
> 
> It is a possibility to embed, say, a JSON data into HTML directly, instead of using a link. This possibility did come up on the EPUB discussion; there are pros and cons of course. I believe that only thing we are saying that, at least at this moment, there is no reason why PWP would disallow this approach. Hence the inclusion in the diagram.
> 
>> 
>> Next, what’s the difference between M1,1 and M3 – I would assume that they are identical, yes?
> 
> Why? To take the example you brought up a while ago, the unpacked version may use the <link> element to some local manifest file in the package (and the same manifest file would then be present in the packed state) but the publisher may want to put things on a server without changing the content of the PWP itself (whether it is in a packed or unpacked state). So no, M1,1 and M3 may very well be different. I guess the typical situation may be, in this situation, that the Lp and Lu values would actually be conveyed to the PWP Client processor via M3 and not via M1,1.
> 
> This is what we agreed upon...
> 
>>  If so, let’s call them the same thing – otherwise someone (like I am doing) will assume they are different things.  And if I am correct that M1,1 from the link in head – what would happen if you ALSO have a link HTTP header?   Do you really get two copies of M3??   That gets confusing in the diagram.
> 
> See above. I do not think it is confusing if things are different.
> 
> Ivan
> 
>> 
>> Bottom line – I wonder if this is getting too complex??
>> 
>> Leonard
>> 
>> From: Ivan Herman <ivan@w3.org>
>> Date: Thursday, March 3, 2016 at 7:32 AM
>> To: W3C Digital Publishing IG <public-digipub-ig@w3.org>
>> Subject: [dpub-loc] New version of the PWP Client processor diagrams
>> Resent-From: <public-digipub-ig@w3.org>
>> Resent-Date: Thu, 3 Mar 2016 12:32:30 +0000
>> 
>> Here they are:
>> 
>> https://w3c.github.io/dpub-pwp-loc/drafts/PWPClient3.svg
>> https://w3c.github.io/dpub-pwp-loc/drafts/PWPClient3.png
>> 
>> I think I have incorporated everything that we discussed yesterday.
>> 
>> 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
> 
> 
> 
>