Re: [dpub-loc] meeting

Hi Leonard, Ivan,

I interpreted your issue a little differently than Ivan, and opened
https://github.com/w3c/dpub-pwp-loc/issues/13 to reflect my interpretation.

Kind regards,
Ben

Ben De Meester
Researcher Semantic Web
Ghent University - iMinds - Data Science Lab | Faculty of Engineering and
Architecture | Department of Electronics and Information Systems
Sint-Pietersnieuwstraat 41, 9000 Ghent, Belgium
t: +32 9 331 49 59 | e: ben.demeester@ugent.be | URL:
http://users.ugent.be/~bjdmeest/

2016-03-09 14:30 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Leonard
>
> (Sorry for the longish response)
>
> All this may be a terminological issue... let us see.
>
> The role of the PWP Processor is, in my view, to provide a separation
> between the PWP rendering layer and handling the various states a PWP can
> be in. Ie, the rendering part has a relatively simple 'view' of the world:
> it considers a PWP *as if* it was a pure, traditional Web site, i.e., a
> collection of Web Resources accessed through HTTP(S), using the canonical
> URL as "the" base locator. Ie, as if the PWP was in an unpacked and
> protocol states, to use the terminology in the current PWP draft
> <http://w3c.github.io/dpub-pwp/#state_definition>.
>
> The role of the PWP processor is fulfilled by providing some sort of a
> "translation" between this ideal world and the real world. It retrieves the
> information from a server in some format and, through some specific
> locators, possibly unpacks data on the fly, caches the content if needed,
> translates among locator values, etc. The diagram describes what the
> processor expects to receive through the usual HTTP(S) channels to set up
> what it needs for processing (essentially the mapping of URL-s).
>
> It is correct that, in *this* definition of the PWP Processor, it is not
> necessarily running in a client only. It is perfectly possible to implement
> a PWP Processor by pushing part of its functionality to a (possibly third
> party) server, and keeping only part of its functionality in a client. In
> that case the PWP Processor is cut into a number of internal processors
> communicating among them in some implementation specific manner, but that
> is a purely implementation specific issue, and it is *not* up to a PWP
> specification to define the modalities. In this sense you are right that a
> PWP Processor is not necessarily bound to a client; the description should
> make this clearer (essentially by not formally referring to client or
> server side). But I do *not* think there is anything else to be defined
> through a PWP specification; there is no separate "server side" PWP
> processor to be described.
>
> All that being said, I think that, realistically, the implementation of a
> PWP Processor would happen primarily on the client-side. I also believe
> that, *conceptually*, it is perfectly fine to look at a PWP Processor as
> a client side entity: that makes it clearer and probably easier to grasp
> for people even if, on the formal specification level, the Processor is
> indeed not strictly bound to a client. Ie, the text have to be made clearer
> or more "pure", although I would certainly add a note referring to a client
> side processor as the most likely implementation strategy.
>
> (There is an analogy. There are browsers, e.g., Opera Mini, which does a
> slightly unusual way of processing: when an HTTP request comes from the
> user, it would not retrieve that resource from the Web like the usual
> browsers; instead, it communicates to a specific server that would do the
> HTTP communication on its behalf, cache the result and send back to the
> client some sort of an optimized, processed version of the content.
> Conceptually, Opera Mini behaves just like any other browser; this
> internal, extra server-client layer is not something the definition of a
> browser would or should care about...)
>
> Ivan
>
> On 9 Mar 2016, at 13:44, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> Why does the specification only concern itself with the client?   We are
> describing a processor – where that processor lives should not be
> relevant.  BUT since we are describing a client-side design, we should also
> be providing for a server-side one as well.
>
> I do agree with you that the model/nature of the server-side PWP processor
> is different than the client side – which is why we need to describe it!
> And it is more than just server-side configuration, it would be actual code
> running on the server.   Which is perfectly acceptable, even if you don’t
> want it for your own setups.
>
> Leonard
>
> From: Ivan Herman <ivan@w3.org>
> Date: Wednesday, March 9, 2016 at 12:46 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: Ben De Meester <ben.demeester@ugent.be>, W3C Digital Publishing IG <
> public-digipub-ig@w3.org>
> Subject: Re: [dpub-loc] meeting
>
>
> On 9 Mar 2016, at 00:55, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> I am not fine with it.   A PWP Processor could be either client or server
> or both.  It needs to be clear that our design supports all of these modes.
>
>
> We have discussed this and we seem to be in a disagreement.
>
> A possible PWP specification describes, normatively, the behaviour of what
> happens on the client side. That is the PWP processor there. It should not
> describe/prescribe what happens on the server side. It may provide possible
> alternatives on how the information, as described *for the PWP Client side
> processor*, can be provided, it can provide good practices and examples,
> server configurations, etc, but it has a fundamentally different nature
> than the client side specification. Calling that server side a PWP
> processor would be misleading and, imho, wrong.
>
> We have a PWP Client Process, and we may have some best practices for
> server setup.
>
> Ivan
>
>
>
> Leonard
>
> From: Ivan Herman <ivan@w3.org>
> Date: Tuesday, March 8, 2016 at 12:08 PM
> To: Ben De Meester <ben.demeester@ugent.be>
> Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
> Subject: Re: [dpub-loc] meeting
> Resent-From: <public-digipub-ig@w3.org>
> Resent-Date: Tue, 8 Mar 2016 17:09:12 +0000
>
>
> On 7 Mar 2016, at 15:08, Ben De Meester <ben.demeester@ugent.be> wrote:
>
> Hi all,
>
> The next locators TF meeting will be on March 9th at 1500 UTC [1]
>
> I have made a first draft of the locators work until now (
> http://w3c.github.io/dpub-pwp-loc/), basically combining all text that we
> already agreed on, and adding issues where consensus is to be reached.
>
>
> Thanks!
>
> Most important change between what we discussed until now and the doc is
> that I currently call the Server-side PWP processor just the `server`, to
> (try to) avoid confusion. So a PWP processor is always assumed client-side.
> If there are any suggestions for better naming, please let me know :).
>
>
> I am, personally, fine with this...
>
> Agenda:
>
> * Going over currently open issues of the doc, finding new issues.
>
> It would be great if we could use the github issue-system (
> https://github.com/w3c/dpub-pwp-loc/issues) to open new issues, so any
> comments on the doc: please open a new github issue! :)
>
>
> Actually, I think we should "transfer" the issues listed in the document
> into the github issue list; it would help us to manage them. That could
> also help in reducing the big rosy blobs in the current document by just,
> essentially, referring to the issues in github, thereby making the document
> more readable…
>
> If you agree, I may find some time tomorrow doing this. Unless you beat me
> into it:-)
>
> Ivan
>
>
> Kind regards, and hear you on Wednesday!
> Ben
>
> [1]
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+Locators&iso=20160309T15
> <http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+Locators&iso=20160210T15>
>
> IRC: #dpub-loc
>
> Topic: DPUB IG Locator Task Force
> Date: Every Wednesday, from Wednesday, January 13, 2016, to Wednesday,
> December 21, 2016
> Time: 10:00 am, Eastern Standard Time (New York, GMT-05:00)
> Meeting Number: 640 269 372
> Meeting Password: Please obtain your meeting password from your host.
> -------------------------------------------------------
> To join the online meeting (Now from mobile devices!)
> -------------------------------------------------------
> 1. Go to
> https://mit.webex.com/mit/j.php?MTID=mec073df570c69d4340ca47564e81b37a
> 2. If requested, enter your name and email address.
> 3. If a password is required, enter the meeting password: Please obtain
> your meeting password from your host.
> 4. Click "Join".
>
> To view in other time zones or languages, please click the link:
> https://mit.webex.com/mit/j.php?MTID=maa411ca7bcf238f6c25818c4ef58f654
>
> -------------------------------------------------------
> To join the audio conference only
> -------------------------------------------------------
> To receive a call back, provide your phone number when you join the
> meeting, or call the number below and enter the access code.
> US Toll Number: +1-617-324-0000
>
> Access code:640 269 372
> Mobile Auto Dial:+1-617-324-0000,,,640269372#
>
>
>
> ----
> 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
>
>
>
>
>
>
> ----
> 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
>
>
>
>
>