Re: [dpup-loc] Diagram for a PWPClient on locators

OK – but the second half of your diagram isn’t correct then with respect to the text here.

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Monday, February 22, 2016 at 2:14 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpup-loc] Diagram for a PWPClient on locators

This is my diagrammatic view of the text below, with possibly some more details:

[[[

For the previous mechanism to work, the following statement, partially answering Q1 seems to be the essential feature:

  *   The answer to HTTP Get http://book.org/published-books/1 must make M available to the PWP Processor

However, there is no one, and only one, way to achieve that. Instead, a PWP Processor must be prepared to some alternatives. The final list of those alternatives should be part of a more precise specification for a PWP; some of the possible variations are as follows. The response of S (i.e., the answer to Q1) is:

  *   M itself (serialized as a JSON file, and RDFa+HTML file, etc.); or
     *   it may be important to return, as part of the HTTP response, a distinctive media type for the serialization of M
  *   a package in some predefined PWP format that must include a manifest containing M (or a subset thereof); or
  *   an HTML, SVG, or other resource, representing, e.g., the cover page of the publication, with M (or a subset thereof) provided through the Link<https://tools.ietf.org/html/rfc5988> header of the HTTP Response; or
  *   an (X)HTML file containing the <link> element referring to M (or a subset thereof)

These possibilities are not mutually exclusive. Each returned information, by itself, may be incomplete (hence the remark 'subset thereof') and a combination of those, or other possibilities, may provide the complete M.

A typical example may be when the manifest file returned from the packed state would not include Lu; this may be returned via the HTTP Response LINK header

Note: The relative priorities of these alternatives must be specified.

]]]

Ivan


On 22 Feb 2016, at 18:54, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

Then I remain confused – because the second half the diagram doesn’t match any current discussions or designs…

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Monday, February 22, 2016 at 12:39 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpup-loc] Diagram for a PWPClient on locators

Just a small note here: my intention was to describe what a PWP Processor should implement in general, to be prepared on what the server _may_ return. In this sense it is orthogonal to the server discussion; how the server implements this is deliberately left silent on the diagram.

Ivan

----
Ivan Herman
+31 641044153

(Written on my mobile. Excuses for brevity and frequent misspellings...)



On 22 Feb 2016, at 16:30, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

Ivan – can you explain your diagram in the context of our server discussion?

The first part of the diagram makes sense regardless of server – since the client could/may either send in ACCEPT headers and/or the server could just return whatever is the default.   No issues there.  NOTE: I do think there is a potential issue with the <link> in the HTML – but we’ll take that up separately.

Given a server w/o any additional code – even one configured to return different types – you would NEVER get extra headers returned.  So I am not sure how the second half of the diagram fits into your “simple server” model.  It is more aligned with my “extended server” models.  And if the server is “extended”, then why bother with the link (which also needs to be resolved, which isn’t covered in the diagram) and just put the entire M(partial) as the return.

Leonard

From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Monday, February 22, 2016 at 10:07 AM
To: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: [dpup-loc] Diagram for a PWPClient on locators
Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Resent-Date: Mon, 22 Feb 2016 15:07:33 +0000

Inspired by Ben, I have also created a diagram on the PWP Client behaviour when retrieving L:

https://rawgit.com/w3c/dpub-pwp-loc/gh-pages/drafts/PWPClient.svg

https://raw.githubusercontent.com/w3c/dpub-pwp-loc/gh-pages/drafts/PWPClient.png


The diagram is incomplete insofar as I have not added SVG as a possible return (which would be a possibility after all); it is a simplified version of the HTML branch, because there is no <link> element of the sort in SVG.

If you want to make any change, I used the https://www.draw.io/ service, and the corresponding XML file is also on the repo:

https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/PWPClient.xml


This is not an alternative to Ben's diagram, but a complement of it I guess.

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