Re: [DPUB] packaging requirements document

Leonard,

I was fairly busy with other things today, so I could not spend too much time on this. I have some responses (and possible actions on the documents) below, but I cannot promise to take care of all of them now. To be continued tomorrow, if needed…

> On 18 Aug 2015, at 18:10 , Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> Not sure the best way to send feedback/comments, so I will do it here.  These are only in the order in which I found them reviewing the doc….
> 
> – Regardless of the fact that someone at the IETF thinks “archive” is the right term, in the document/publication space it is NOT.  I would strongly recommend that we NOT refer to that document or that terminology.

During the discussion on the mailing list we were asked to put a concise definition for a package into the document. (I believe what IETF considered as archive in their exploration for providing a top level media type for packages is actually of a similar goal.) Do you have a beter replacement?

> 
> - I have problems with this phrase “ This is, however, different from the cached state of a networked publication, which does not have a separate existence (though can also be used offline).”.  There are many ways to cache, some of which are related to browser-based technology and some of which are not.  But all of which constitute the concept of a “cached and offline” document.   How about just removing this.  I don’t think it adds anything, certainly not at this point in the document.
> 

The text (tries to) refer to browser based caches here. I am not sure what the problem is with the statement, though: there is clear difference between what we call a portable state, which is, in practice, a file independently of the reading system/browser being used, and the cache within the reading system. The former can be manipulated independently, the latter cannot. Do you have a better way of formulating this?


> - Related to the two items above, the definitions of 2 & 3 are incorrect and need to be changed to reflect the above recommendations.
> 
> - I don't believe that anyone has suggested that the transition of states “should be transparent for a reading system”.  It should be completely lossless (or better, w/o any changes) to the publication itself.  However, I would absolutely expect that an online reading system be quite different from an RS for portable content – if only because it may/will have to look inside a package (that may not exist for the online version).

Right, this is a bit more complicated. What I think was meant is that the rendering and possibly interactive part of the reading system independent of the state, ie, the change on that is indeed transparent. (Because, for example, it is all proxied in a service worker.) I have added some words to make that, hopefully, clearer.

> 
> - The phrase “ It should maintain its integrity over time” isn’t actually something that we, as the file format specification, have any control over. It is more about the media, systems, etc. in which the content is stored.  As such, it should be removed.

Hm. If I reboot my machine, the cache will disappear, but a portable document on my disc will remain. I am not sure what the problem is with this.

> 
> - I believe we have many more use cases.  Did you only want to put a small number here?
> 

I think we did not want to put a lot of use case into this document (otherwise it makes it difficult to follow) and would rather rely on another page to collect those. There are some that are already referred to, the more the better!

> - Are there no other requirements for the portable state?  I believe we had some in our existing use case/requirements specs.   If not, I can think of a few that I would add here.
> 

I would very welcome that.

> - In the first paragraph of Streamability, you have multiple references to HTTP, which doesn’t make any sense in the portable case (and may not in the cached case).  If you simply removed both instances of HTTP, the paragraph is more general and still makes perfect sense.   Also remember that streamability applies to various other contexts as well beyond an HTTP-based network.
> 

This is something I will have to think more about. The issue is that the streamability may make something different depending on the state. For a Portable Document, the way the package format is defined should allow for easy streaming, but that is a bit of a different mechanism than for an online state. Maybe these are so different that this requirement should move to the separate section on portable states?


> - The fourth bullet in Use cases for streamability refers to EPUB inappropriately after the phase “Web Publication” - but throughout the rest of this document that is a generic term referring to both online and offline content.  Remove the (eg. EPUB) as it’s not correct here.

It says (e.g., EPUB), ie, it is an example… but I have removed it.

> 
> - The fifth bullet in Use cases for streamability doesn’t need to the second sentence, as it is implied by the first (and also introduces EPUB for no valid reason).  I would recommend removing that sentence.
> 

Done.

> - In the use cases to Stable Links, there is the parenthetical “(as opposed to the PDF)” which is not only invalid/incorrect but also not necessary.   I would remove that.
> 

Done.

> - In the Update new components only, there is a potential technical recommendation “(This can rely on functionality like HTTP 304.)" – but it’s putting the cart before the horse and may only confuse.  I would recommend that you remove it.
> 

True. It is a technical detail that may or may not be relevant; removed.

> - In the Package in a Package section, you have “This is trivially available in online and cached states, but puts an extra requirement on portable states.”  This appears to be a copy/paste from elsewhere, as it doesn’t belong here because it’s simply not true in this case.  Please remove.

It is a copy paste indeed, but is it incorrect? (It may be superfluous, though).

> 
> - The Access to package section also has a similar note about “trivially available” which is also not true, and I would recommend removal as well.
> 

I have re-written that sentence in a way that, I believe, is correct…

Thanks

Ivan

> 
> Other than  that – looks good!
> 
> Leonard
> 
> From: "Siegman, Tzviya - Hoboken"
> Date: Tuesday, August 18, 2015 at 11:35 AM
> To: "DPUB mailing list (public-digipub-ig@w3.org)"
> Subject: [DPUB] packaging requirements document
> Resent-From: <public-digipub-ig@w3.org>
> Resent-Date: Tuesday, August 18, 2015 at 11:36 AM
> 
> Hello DPUBbers,
> 
> Please review the current draft of Requirements for Web Publication and Packaging [1]. We are preparing this note to send to our colleagues who worked on Packaging [2]. Do you recommend any edits? Is this document complete?
> 
> Thank you
> 
> [1] https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Publication_and_Packaging
> [2] http://www.w3.org/TR/web-packaging/
> 
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704