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

Hi Ivan,

Well since you and I agree that "if there is a dependency on a server
process it is not portable", then we are in agreement on what I consider
fundamental, the rest is only word-smithing.

Regarding finiteness, I'm not sure what is hard to understand about
"finite" or "enumerable". The normal case is that a resource of a portable
document has only one representation, i.e. it is "static" content. The
fancier cases might be if there were say French, German, and English
versions of a text resource, or different resolutions of an image resource,
but all were predefined. So my attempt was to use "formats are finite and
enumerable" to encompass these fancier cases, and also encompass the case
of concierge server processes that simply fetch resources from e.g. a DB,
in place of just saying "static content". But to me "static content" is
really the notion.

Again if a resource is code, e.g. JavaScript, I consider the format to be
the code itself not the side-effects of its execution. So if the dashboard
was, in your elaboration of earlier example "part of a larger Web document
that teaches information visualization where the dashboard is an example"
then as long as that dashboard's embodiment is JavaScript code intended to
execute on the client, then it can be portable. If that dashboard's
embodiment was a Python script designed to run on a server, it is not  since
that would be a dependency on a server process.

I guess my problem with describing this in operational terms is that I
believe that portability should be determinable through static analysis...
otherwise how can we say whether something is portable or not?

Again in case of PDF and EPUB we have a very objective definition of
portability, because of the package containment (with a few leaks / gray
areas as previously discussed, such as fonts in the case of PDF and
external video files in the case of EPUB). I don't  believe that for
Portable Web Documents we have any reason to back off from aspiring to a
similar level of objectivity.

--Bill


On Thu, Sep 10, 2015 at 11:15 AM, Ivan Herman <ivan@w3.org> wrote:

> 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
>
>