Re: [dpub-loc] 20160217 minutes

Daniel,

to be honest, I am not sure what you are arguing for or against…

- The fact that the unpacked and packed versions would/should reflect, conceptually, the same file hierarchy: I do not have any problem with that. Although we could imagine having some sort of a 'mapping table' in the PWP manifest to convert among URLs from one state or the other, I do not think that is really all that useful. However, I do not think anything in the current writeups contradicts this; in fact, I believe this issue is pretty much orthogonal on the choice of the Lu, L, Lp, and the relationships among them.

- I did not say that 'content negotiation is the lowest common denominator'. It is one of the possible approaches. I happen to think it is useful and good to have it, others have a different view; that is fine. The only thing in the text is: "The answer to HTTP Get http://book.org/published-books/1 must make M available to the PWP Processor". The way to honour that commitment may include several approaches which, if we were writing a standard, would be the only normative statements and are listed (for the time being, there may be more) in the four bullet items as alternatives:

 • M itself (e.g., a JSON file, and RDFa+HTML file, etc., whatever is specified for the exact format and media type of M at some point); or
 • a package in some predefined PWP format that must include M; or
 • an HTML, SVG, or other resource, representing, e.g., the cover page of the publication, with M referred to in the Link header of the HTTP Response; or
 • an (X)HTML file containing the <link> element referring to M

Nothing here prescribes a specific server setup. Again, in standard specification parlance, all the various server setup possibilities are informative and not normative.

Ivan

P.S. I am also not fully sure what you want to show with the github example, I must admit. But it seems to reflect a particular github (server:-) setup. Let me give another example: you can run the following curl-s:

curl --head http://www.w3.org/ns/oa
curl --head --header "Accept: application/ld+json" http://www.w3.org/ns/oa
curl --head --header "Accept: text/turtle" http://www.w3.org/ns/oa

these will return the same conceptual content (a vocabulary) in HTML (with the vocabulary in RDFa), in JSON-LD, or in turtle, using the same canonical URL for the vocabulary itself. This requires a different server setup.




> On 18 Feb 2016, at 14:04, Daniel Weck <daniel.weck@gmail.com> wrote:
> 
> Hello,
> 
> here's a concrete example (unrelated to PWP) which I think illustrates
> the comments made during the concall, regarding content negotiation
> vs. dereferencing URL endpoints to "meta" data about the publication
> locators for unpacked / packed states.
> 
> Let's consider the GitHub HTTP API, the w3c/dpub-pwp-loc GitHub
> repository, and the README.md file located at the root of the
> gh-branch. There's a "canonical" URL for that (you can safely click on
> the links below):
> 
> curl --head https://api.github.com/repos/w3c/dpub-pwp-loc/readme
> ==> Content-Type: application/json; charset=utf-8
> 
> curl https://api.github.com/repos/w3c/dpub-pwp-loc/readme
> ==> "url": "https://api.github.com/repos/w3c/dpub-pwp-loc/contents/README.md?ref=gh-pages"
> 
> As a consumer of that JSON-based API, I can query the actual payload
> that I'm interested in:
> curl https://api.github.com/repos/w3c/dpub-pwp-loc/contents/README.md?ref=gh-pages
> ==> "content": "BASE64"
> 
> 
> Now, back to PWP:
> 
> State-agnostic "canonical" URL:
> https://domain.com/path/to/book1
> (note that this could also be a totally different syntax, e.g.
> https://domain.com/info/?get=book1 or
> https://domain.com/book1?get=info etc. for as long as a request
> returns a content-type that a PWP processor / reading-system can
> consume, e.g. application/json or application/pwp-info+json ... or XML
> / whatever)
> A simple request to this URL could return (minimal JSON example, just
> for illustration purposes):
> {
>    "packed": "https://domain.com/path/to/book1.pwp",
>    "unpacked":
> "https://domain.com/another/path/to/book1/manifest.json"  /// (or
> container.xml, or package.opf ... :)
> }
> 
> Once again, there is no naming convention / constraint on the "packed"
> URL https://domain.com/path/to/book1.pwp which could be
> https://domain.com/download/book1 or
> https://download.domain.com/?get=book1 , as long as a request returns
> a payload with content-type application/pwp+zip (for example). Note
> that the book1.pwp archive in my example would contain the "main entry
> point" manifest.json (thus why I made a parallel above with EPUB
> container.xml or package.opf)
> 
> The "unpacked" URL path
> https://domain.com/another/path/to/book1/manifest.json does not have
> to represent the actual file structure on the server, but it's a
> useful syntactical convention because other resource files in the PWP
> would probably have similarly-rooted relative locator paths (against a
> given base href), e.g.:
> https://domain.com/another/path/to/book1/index.html
> https://domain.com/another/path/to/book1/images/logo.png
> In other words, if the packed book1.pwp contains index.html with <img
> src="./images/logo.png" />, it does make sense for the online unpacked
> state to use the same path references (as per the example URLs above).
> Publishers may have the option to route URLs any way they like, e.g.
> <img src="?get_image=logo.png" />, but we know there is the issue of
> mapping document URLs in packed/unpacked states with some canonical
> locator, so that annotation targets can be referenced and resolved
> consistently. So it would greatly help if the file structure inside
> the packed book1.pwp was replicated exactly in the URL patterns used
> for deploying the unpacked state.
> 
> To conclude, I am probably missing something (Ivan and Leonard, you
> guys are ahead of the curve compared to me), but I hope I managed to
> convey useful arguments. Personally, as a developer involved in
> reading-system implementations, and as someone who would like to
> continue deploying content with minimal server-side requirements, I am
> not yet convinced that content negotiation is needed here. As an
> optional feature, sure, but not as the lowest common denominator.
> 
> Thanks for listening :)
> Regards, Dan
> 
> 
> 
> On Thu, Feb 18, 2016 at 12:04 PM, Ivan Herman <ivan@w3.org> wrote:
>> With the caveat that the minutes are always difficult to read (Romain, that
>> is not your fault, it is the case for most of the minutes; I know only a few
>> people who write perfect minutes, and I am certainly not among them) maybe
>> some comments on my side. More about this next time we can all talk
>> (although it seems that this will only be in two weeks, due to the Baltimore
>> EDUPUB meeting).
>> 
>> First of all, this comment:
>> 
>> [[[
>> rom: my issue is that the spec doesn't say "if Lu exists then L must be Lu",
>> I think we should consider it
>> ]]]
>> 
>> I do not see why we should say anything like that. It is of course correct
>> that, in many cases, it makes a lot of sense to have Lu=L. But I do not see
>> why we should restrict it this way. In general, the approach I tried to
>> follow in my writeup is to be as permissive as possible and put the minimum
>> possible hard requirements on the locator setup. It is probably worth adding
>> a note in the text (or the more final text) that Lu may be equal to L (in
>> fact, this may very well be a widely used approach) but I would not want to
>> go beyond that.
>> 
>> Then there is the whole issue about content negotiations… It seems that we
>> have a disagreement on the value and usage of content negotiations. I do not
>> agree with Daniel's statement that "in a RESTful API the URL would
>> consistently return the same content type". It is certainly not the
>> practice, nor should it be. Content negotiation is widely used when tools
>> want to retrieve, for example the best syntax that encodes a particular
>> information (typical example is in RDF land, where tools may or may not have
>> parsers for a particular RDF serialization), this is how dbpedia is set up
>> etc. (I did told you about the way RDF namespace documents are set up on our
>> site, for example. It is pretty much general practice to do that.) I must
>> admit I also do not agree with Daniel's remark on "content negotiation based
>> on (sophisticated) HTTP headers sounds counter intuitive". Content
>> negotiations is certainly very intuitive to me...
>> 
>> All that being said, and that is where maybe there is actually a minor
>> disagreement between Leonard and I: I do not say that content negotiation is
>> the only approach to set up a server storage. The text I wrote is
>> deliberately open ended insofar as it described what the client expectation
>> is when that GET request is issued in general terms, and the choice among
>> the various alternatives are all the server's. The list of possible server
>> behaviours in the text are possible alternatives, instead of hard
>> requirements. The client is responsible in following the various possible
>> paths and, maybe, we will have to describe those possibilities later in more
>> details (precise usage of the LINK header, the <link> element, media types,
>> etc), but that gives the liberty to set up the server the way the publisher
>> wants. If we accept this approach, ie, that the client has some complexity
>> to resolve in favour of a variety of possible server setups, then I do not
>> think there is a major disagreement among us.
>> 
>> Talk to you guys later…
>> 
>> Ivan
>> 
>> B.t.w., a more general and slightly philosophical comment: we should not be
>> afraid of really using HTTP:-) The various header information in both the
>> request and response headers of an HTTP request/response are very rich and
>> sophisticated. There are many situations, on expiration dates, on security,
>> etc, and of course content negotiations that can be expressed via these HTTP
>> headers, and we should not shy away using those whenever we can and it makes
>> sense. As I showed in one of may mails it is not that complex to set up
>> (actually, and to be fair, setting up content negotiations is probably the
>> more complex thing, I accept that).
>> 
>> If you are interested by the various possibilities, this site may be of
>> interest:
>> 
>> https://github.com/dret/sedola/blob/master/MD/headers.md
>> 
>> 
>> 
>> On 18 Feb 2016, at 09:24, Romain <rdeltour@gmail.com> wrote:
>> 
>> 
>> On 18 Feb 2016, at 02:49, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> 
>> Actually, the big issue that I took away from the minutes is that ivan and I
>> are in agreement that content negotiation (via standard web technique incl.
>> the Accept header) is the proper way for the client & server to decide what
>> to return on the GET from the canonical locator.   Daniel, however, appears
>> (from the minutes) to be promoting a completely different approach.
>> 
>> 
>> As stated before [1], I am absolutely not convinced that content negotiation
>> is a good approach.
>> I want to upload a PWP tomorrow to a static file hosting service; if conneg
>> is required I can't do that.
>> 
>> More to the point: how to you GET the (manifest + Lu + Lp) info with the
>> conneg solution? Maybe I just miss something.
>> 
>> Finally, may I turn the question the other way around: what are the benefits
>> of content negotiation for the canonical locator? (compared to an
>> alternative approach with explicit links in the GET answer (headers or
>> payload).
>> 
>> Thanks,
>> Romain.
>> 
>> [1] https://lists.w3.org/Archives/Public/public-digipub-ig/2016Jan/0136.html
>> 
>> 
>> Daniel, if you can explain why you want to do something different from the
>> standard web/REST model, I’d like to understand.
>> 
>> Leonard
>> 
>> From: Romain <rdeltour@gmail.com>
>> Date: Wednesday, February 17, 2016 at 6:26 PM
>> To: Daniel Weck <daniel.weck@gmail.com>, Leonard Rosenthol
>> <lrosenth@adobe.com>
>> Cc: "DPUB mailing list (public-digipub-ig@w3.org)"
>> <public-digipub-ig@w3.org>, Tzviya Siegman <tsiegman@wiley.com>
>> Subject: Re: [dpub-loc] 20160217 minutes
>> 
>> On 17 Feb 2016, at 23:12, Daniel Weck <daniel.weck@gmail.com> wrote:
>> 
>> Hi Leonard, that's quite a bold statement, but I suspect the minutes could
>> do with a few corrections.
>> 
>> My bad if the minutes are inaccurate, please feel free to amend. It was a
>> bit frustrating too: several times I wanted to talk or precise a point but
>> was busy typing.
>> 
>> At any rate, I look forward to the recap from you and Ivan at the next
>> opportunity. PS: it was a small quorum on this concall, but I was under the
>> impression that the participants agreed on the broad lines of your proposal,
>> with only details to clarify.
>> 
>> My impression is that participants generally agreed with the presentation of
>> the issues and some principles. I believe that the main point that is still
>> controversial is really what should be the answer to a GET on the canonical
>> locator.
>> 
>>> I think we need to go do this over again next week – which si extremely
>>> unfortunate.
>> 
>> 
>> If I'm not mistaken Matt, Markus, Tzviya and I won't be able to attend
>> (EDUPUB summit).
>> 
>> Romain.
>> 
>> Regards, Daniel
>> 
>> On 17 Feb 2016 9:17 p.m., "Leonard Rosenthol" <lrosenth@adobe.com> wrote:
>>> 
>>> Sorry that I was unable to attend today, especially since the discussion
>>> (based on the minutes) seems to completely undo all the work that Ivan,
>>> myself and others did on the mailing list during the past week.   The
>>> position presented by Daniel is the exact opposite of what Ivan’s musings
>>> (adjusted based on mail conversations) presented.
>>> 
>>> I think we need to go do this over again next week – which si extremely
>>> unfortunate.
>>> 
>>> Leonard
>>> 
>>> Fro  "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
>>> Date: Wednesday, February 17, 2016 at 11:46 AM
>>> To: "DPUB mailing list (public-digipub-ig@w3.org)"
>>> <public-digipub-ig@w3.org>
>>> Subject: [dpub-loc] 20160217 minutes
>>> Resent-From: <public-digipub-ig@w3.org>
>>> Resent-Date: Wednesday, February 17, 2016 at 11:48 AM
>>> 
>>> Minutes from today’s meeting:
>>> https://www.w3.org/2016/02/17-dpub-loc-minutes.html
>>> 
>>> Tzviya Siegman
>>> Digital Book Standards & Capabilities Lead
>>> Wiley
>>> 201-748-6884
>>> tsiegman@wiley.com
>>> 
>> 
>> 
>> 
>> 
>> 
>> ----
>> 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