W3C home > Mailing lists > Public > public-digipub-ig@w3.org > September 2015

Re: [Glossary] Definition of a portable document (and other things...)

From: Ivan Herman <ivan@w3.org>
Date: Thu, 10 Sep 2015 20:15:49 +0200
Cc: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Deborah Kaplan <dkaplan@safaribooksonline.com>, Liam Quin <liam@w3.org>, Ralph Swick <swick@w3.org>, Olaf Drümmer <olaf@druemmer.com>
Message-Id: <63B9E2F5-DB67-4BDB-9C6D-72B74A87CC33@w3.org>
To: Bill McCoy <bmccoy@idpf.org>
Bill, 

sorry if I am terse, writing a longer mail on an iPad mini is a challenge...

- we agree that if there is a dependency on a server process it is not portable. I do not think I said otherwise...

- I did not "reject" your finiteness notion it is just that... I do not really understand it. Neither do I understand the enumeration notion in this sense. Hence my approach of describing in somewhat more operational terms what portability means in this case; it seems that this did not work with you:-( I would really appreciate if you could provide an alternative definition...

- I am not sure we can define things without a level of anthropomorphism. The decision on portability has a level of fuzziness that we cannot avoid, like Leonard's dashboard example...

More tomorrow...

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



> On 10 Sep 2015, at 19:04, Bill McCoy <bmccoy@idpf.org> wrote:
> 
> Actually the second bullet as presently worded is too vague to capture my notion of a portable document, even with the "MUST".
> 
> If a "Portable Web Document" depends on active processes running on servers, then it is not portable, whether or not these scripts depend on Web Resources external to the Portable Web Document. If my Web Document incorporates a Python program running on the server that manipulates every image based on the phase of the moon, I cant pickle that Python program up and transmit it along with the rest of the Web Resources. So by my criteria it is not portable, at all. But it seems to meet the definition, since the processing only relies on the images, not on external resources.
> 
> Ivan, you seem to be implicitly rejecting (by not adopting it) my suggestion that we nail down specifically that to qualify as portable, the set of representations (formats) for all of resources must be finite. I would love to see an example from you of a Web Document that should qualify as "portable" where that is not true. Maybe we just have a different meaning about "portability" - if you (and perhaps this group) want to define "portability" in a way that does not guarantee the ability to support archival or multi-channel distribution, I guess I don't object. I just don't think it matches how we have historically used "portable" when applied to "documents", so it may create confusion.
> 
> Another way to state my issue is that I believe "portable" should NOT be defined in a way that is human-centric. "portability" is an important attribute as much for machine-machine communication (distributing content to aggregators, semantic analysis, etc.) as for human consumption. The current definition therefore seems to me to be way too anthropocentric with "present the essential content" and "graceful degradation".  Also I'm not sure what "it is offline" means - we are talking about a collection of Web Resources here so what does it mean for them to be offline? It seems we are trying extra hard in this definition to tiptoe around what I see as a very basic and simple property that requires, for Portable Web Documents, a restriction on the REST architecture's general flexibility (that resources aren't bound to specific representations), and by consequence implies that interactivity (other than concierge-level interactivity, such as fetching resources from DBs and perhaps choosing which of a set of resources to fulfill) may only be enabled through "code-on-demand", i.e. code that is is itself a resource of the document.
> 
> So I would much prefer a crisper, simpler, and more objectively ascertainable definition of  "Portable Web Document" which explicitly rules out necessary server-side interactivity by pinning down that the formats for all resources are predefined ("finite and enumerable" or some better wording), rather than all this vague stuff about "essential" and "graceful".
> 
> But, maybe that's just me... ;-)
> 
> --Bill
> 
> 
> 
>> On Thu, Sep 10, 2015 at 7:24 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> I think we are almost there…
>> 
>> However, I would prefer to the MUST in the second bullet as a SHOULD (strong recommendation, not requirement).  I know this is the one point on which Bill and I disagree, but we have some actual use cases where this comes up.  Also, in my mind, this is the “cached” state for the PWD – where it would normally get something online but when not connected it could/would use something local (but not part of the document).
>> 
>> Leonard
>> 
>> From: Ivan Herman
>> Date: Thursday, September 10, 2015 at 7:24 AM
>> To: Bill McCoy
>> Cc: W3C Digital Publishing IG, Deborah Kaplan, Liam Quin, Leonard Rosenthol, Ralph Swick, Olaf Drümmer
>> Subject: Re: [Glossary] Definition of a portable document (and other things...)
>> 
>> Bill,
>> 
>> just picking up where we were yesterday, to settle the last few meters:-)
>> 
>> We seem to be in agreement in the definition of Web Resources, and Web Documents[1]; let us not repeat them here. What we want is a refinement of the portable part. At present, we have:
>> 
>> • A Portable Web Document: a Web Document which contains, within its constituent set, the information necessary to provide delivery of essential content and functionality, or a graceful degradation thereof, without the presence of any other Web Resources.
>> 
>> Following the idea I had yesterday evening, and also following Deborah's approach on adding some 'explanation' to the terms, what about adding the following two items:
>> 
>> [[[
>> • It must be possible to present the essential content of a Portable Web Document even if it is offline (though possibly with a lower quality, e.g., using suboptimal, but local fonts, or images instead of a remote video).
>> 
>> • Active processes (e.g., scripts) of a Portable Web Document, when responsible for an essential functionality, must not depend on Web Resources external to the Portable Web Document.
>> ]]]
>> 
>> I was wondering about adding to the second post: "apart from the standards defined for Portable Web Documents, i.e., programming environments and standard API-s available in User Agents", but that might become to much details. This is not mathematics, after all:-)
>> 
>> Any more such "qualifying" notes? Are those fine?
>> 
>> I think that if we find a consensus on this part, we are done with the first round of glossary definitions… But there are more!
>> 
>> Ivan
>> 
>> [1] https://www.w3.org/dpub/IG/wiki/Glossary
>> 
>> ----
>> 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
> 
> 
> 
> -- 
> 
> Bill McCoy
> Executive Director
> International Digital Publishing Forum (IDPF)
> email: bmccoy@idpf.org
> mobile: +1 206 353 0233
> 

Received on Thursday, 10 September 2015 18:16:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:12 UTC