W3C home > Mailing lists > Public > public-digipub-ig@w3.org > March 2016

Re: [dpub-loc] meeting

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Wed, 9 Mar 2016 12:51:16 +0000
To: Ben De Meester <ben.demeester@ugent.be>, Mike Perlman <perlmanm@me.com>
CC: Ivan Herman <ivan@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <30C5D239-9A14-4D5C-9E28-1C857A1C7045@adobe.com>
Yes, those are good facts that I agree with completely.

What I do not agree with is the last fragment of the definition of server - “ but this is not defined by this document”.  My position is that potential definitions of the server-side operations are as valid (or potentially more so) than the client and should be present in the document as well.

Leonard

From: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>
Date: Wednesday, March 9, 2016 at 3:09 AM
To: Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>
Cc: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpub-loc] meeting

Leonard, am I correct in thinking that you are aiming at the fact(s) that

  *   a server will always need a minimal configuration (so, even in its simplest form, the server needs to perform a minimal amount of processing), but might be a lot more complex to allow for more complex functionalities on the server-side?
  *   This extra functionalities could make the client-side processing more efficient, for example, being able to retrieve a resource within a packed PWP at the server-side, so that the client doesn't have to unpack the PWP locally.
  *   Our model should not (and I don't think it currently does) disallow the fact that this server might be more complex.

Maybe, the definitions at http://w3c.github.io/dpub-pwp-loc/#dfn-pwp-processor and http://w3c.github.io/dpub-pwp-loc/#dfn-server are sufficient, but an extra section is needed to further clarify this?

What do you think? Am I missing something?

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<mailto:ben.demeester@ugent.be> | URL:  http://users.ugent.be/~bjdmeest/


2016-03-09 8:45 GMT+01:00 Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>:
I don’t understand the relevance of server-side processing to PWP.
The PWP loads in a user’s browser. If for some reason it needs to retrieve something from somewhere else, it gets it if the user is online.
These should be requests for static data - media, text, whatever.
But the processing is still local.

On 09 Mar 2016, at 06:46, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> wrote:


On 9 Mar 2016, at 00:55, Leonard Rosenthol <lrosenth@adobe.com<mailto: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<mailto:ivan@w3.org>>
Date: Tuesday, March 8, 2016 at 12:08 PM
To: Ben De Meester <ben.demeester@ugent.be<mailto:ben.demeester@ugent.be>>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: [dpub-loc] meeting
Resent-From: <public-digipub-ig@w3.org<mailto: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<mailto: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<tel:%2B1-617-324-0000>

Access code:640 269 372
Mobile Auto Dial:+1-617-324-0000<tel:%2B1-617-324-0000>,,,640269372#


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/

mobile: +31-641044153<tel:%2B31-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<tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704







Received on Wednesday, 9 March 2016 12:51:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:41 UTC