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

so that’s interesting, Bill.

To me, as noted in my previous messages and that you’ve copied below, the word “Web” refers to the technologies involved and says nothing about the state of the document.   I guess that’s why I was previously using OWP, so that it was clear that it’s related to the technology choices.  And I DO think that it is important that the distinction be made that these things (currently being discussed as (Portable) Web Documents) consist entirely of OWP technologies, so that they can be properly rendered by standard OWP UA’s.  Because what happens to your definition of “portable” if a document contains some unique format that one (or more) UA’s can’t fathom!?!  (yes, Polyfill’s could potentially apply here, but that opens up another can of worms)

I can see your distinction between resource and representation – and I am fine with that.  I still agree that there are some complexities to work out but we can get through those, I believe.

Leonard

From: Bill McCoy
Date: Friday, September 11, 2015 at 11:10 AM
To: Leonard Rosenthol
Cc: Ivan Herman, W3C Digital Publishing IG, Olaf Drümmer, Deborah Kaplan, Liam Quin, Ralph Swick, Tzviya - Hoboken Siegman
Subject: Re: [Glossary] Definition of a portable document (and other things...)

Hi just to chime in and respond to a couple of points of Leonard's -

First,  it is not correct that I was suggesting or agreed with Leonard that "a 'Portable Web Document' can only exist in an offline state". In fact I think that the native state of a "Portable Web Document" should be considered to be online (given the name). What I do hold to is a pretty strong notion of equivalence between a  'Portable Web Document' in its native state and in a cached or transportable offline states (in the transportable offline state I consider it to be, at least temporarily, identical to a plain old "Portable Document").

Secondly, I think we are sometimes using "resource" in a loose way. In the context of "Web Resources", I took Ivan's intended definition as to be consistent with the REST architectural style, where a resource is an agent that responds to requests with representations of itself. In the case of HTTP URLs these requests are of course GET requests.  We can speak of formats only when we talk about the representations of a resource. So when Leonard writes "the same image online and offline is still the same 'web resource'" I don't agree, because "http://foo.com/bar.jpg" may be a Python program that generates that image on the fly (rather than say an Apache server that grabs a JPG from a filesystem directory and returns is)... the web resource is either way, to me, the the http:// URL and the agent triggered by requests thereto, not the JPEG image data that the agent returns in response to requests.  The key point for me is that, when used in something that we would consider to be a "Portable Web Document", the agent must not be dynamically generating different JPEG images

It may seem over-complicated to sustain this "resource" vs. "representation" dichotomy, but I think in the end it will help us be clear on what is going on through all these state transitions. And, it is part of the Web's fundamental architecture, not just per an influential PhD thesis but as subsequently blessed in a W3C standard (http://www.w3.org/TR/webarch/).

Maybe we thus need another term when we want to refer to representations (e.g. the actual JPEG data), I like the term "content", but I am OK with Ivan's use of "formats". EPUB specs presently use the term "Publication Resource". Or if we want to use the term "resource" to refer to representations then I think we should be clear that we are so doing to avoid confusion wrt resource/representation in Web Architecture terms (esp. when we are talking about Web Resources).

Lastly I don't 100% agree with Leonard that the content/formats/representations/resources we are here talking about must always be in OWP native formats to qualify the result as a "Portable Web Document".  For example a JavaScript program operating on data like CSV or some even more proprietary data format could be just as portable (according to my idea of portability anyway) as content that was wholly in HTML and CSS. But yet I do think this is kind of a exception case, and that in the normal case yes we should expect that the content must be in OWP native formats, and where that is not the case then it must be fodder for document-resident interactivity.

--Bill


On Fri, Sep 11, 2015 at 6:49 AM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
Ivan – I don’t believe you correct reflected the discussions of yesterday.

My understanding of the discussion between myself and Bill M was that a “Web Document” can be in different states, but that a “Portable Web Document” can only exist in an offline state.  That’s a significant difference from what you are proposing below.

> would think that this is not the subject of discourse for this Interest Group which, after all,
>"just" wants to set up a framework for Digital Publishing and the Web
>
While I recognize that this group was formed to focus on the particular needs of Digital Publishing – if the group is going to take on defining globally applicable terms (such as Web Document and Portable Web Document), then those definitions MUST be general purpose as well!   Either that or we should pick terms that are focused strictly on DigPub.

>• A Web Resource in a Web Document is Portable if an OWP compliant user agent can render its essential content by relying exclusively on the Web >Resources within the same Web Document.
>• A Portable Web Document is a Web Document whose all constituent Web Resources are Portable.
>
On the surface, these definitions sounds reasonable.  Unfortunately, as soon as you start diving into them, they fall down fairly quickly.   Let me give a simple and easy case (using EPUB as an example of a Portable Web Document):
- An EPUB that uses CSS such as { font-family: Helvetica } will not qualify since the OWP UA is using a resource not in the document.

> EPUB+WEB document
>
Can we PLEASE rename that document?   That was how I started this conversation, in that it has already picked a specific technology to solve a problem.  Instead, that should be the “Portable Web Document” document…


Leonard

From: Ivan Herman
Date: Friday, September 11, 2015 at 8:40 AM
To: W3C Digital Publishing IG
Cc: Bill McCoy, Olaf Drümmer, Deborah Kaplan, Liam Quin, Ralph Swick, Leonard Rosenthol, Tzviya - Hoboken Siegman
Subject: Re: [Glossary] Definition of a portable document (and other things...)

Good morning/afternoon

here is your friendly daily summary:-) to start the next round. Maybe the last? (That would be a good way to close the week-end:-)

As far as I am concerned, the most important outcome of the last round is the recognition that we may mix the definition of the various documents and their states. I fully agree with Tzviya that we should separate the details of that discussion for a separate thread; just to build the bridge to that thread I believe that:

- We (will:-) have the notion of a Portable Web Document
- A Portable Web Document may be in an online, cached, or offline state

It is of course true that a (not necessarily portable) Web Documents may also be in a cashed state, for example. Also, as was discussed on the thread, a general Web Document may be transformed into a Portable Web Document (e.g., dumping its snapshot into a PDF file), but I would think that this is not the subject of discourse for this Interest Group which, after all, "just" wants to set up a framework for Digital Publishing and the Web, ie, EPUB+WEB. We should limit ourselves in our discussion…

With that… getting back to the issue at hand, ie, the definitions. As a reminder, I reproduced the previous definition below (after my signature). Well, the remaining issue, of course, was to define what exactly the portability is. After looking at Bill's and Deborah's formulations, I was more inspired by the latter (sorry Bill…) but, I believe and as Bill said, we are really at the word-smithing stage here. So here it goes:

[[[
• A Web Resource is a ... (see the current glossary [1])

• Web Document is a ... (see the current glossary [1])

• A Web Resource in a Web Document is Portable if an OWP compliant user agent can render its essential content by relying exclusively on the Web Resources within the same Web Document.

• A Portable Web Document is a Web Document whose all constituent Web Resources are Portable.
]]]

I have refreshed [1] to reflect the whole definition.

How does that sound? Is this an acceptable consensus?

Ivan

P.S. Once we have the discussion closed it is probably useful to provide some explanatory text and, especially, to collect and document the various examples we had in the discussion. They will be very useful in explaining the terms. I am happy to do that once we are done…

P.S.2. This terminological discussion may also influence the way we formulate the next release of the EPUB+WEB document. Actually, this was one of the issues that triggered me to start this thread...


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


Here is the previous version:

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

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






--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233