Re: [dpub-loc] 20160217 minutes

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 <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 <mailto: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 <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 <mailto:rdeltour@gmail.com>>
>> Date: Wednesday, February 17, 2016 at 6:26 PM
>> To: Daniel Weck <daniel.weck@gmail.com <mailto:daniel.weck@gmail.com>>, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
>> Cc: "DPUB mailing list (public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>, Tzviya Siegman <tsiegman@wiley.com <mailto:tsiegman@wiley.com>>
>> Subject: Re: [dpub-loc] 20160217 minutes
>> 
>>> On 17 Feb 2016, at 23:12, Daniel Weck <daniel.weck@gmail.com <mailto: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 <mailto: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 <mailto:tsiegman@wiley.com>>
>>>> Date: Wednesday, February 17, 2016 at 11:46 AM
>>>> To: "DPUB mailing list (public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>>>> Subject: [dpub-loc] 20160217 minutes
>>>> Resent-From: <public-digipub-ig@w3.org <mailto: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 <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 <mailto: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