- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 15 Sep 2015 16:12:28 +0200
- To: Brady Duga <duga@google.com>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>, Ralph Swick <swick@w3.org>
- Message-Id: <3368251F-5CA8-4CEC-A6F8-CB92DB12C21E@w3.org>
> On 15 Sep 2015, at 14:53 , Brady Duga <duga@google.com> wrote: > > > > On Mon, Sep 14, 2015 at 9:56 PM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote: > >> On 14 Sep 2015, at 15:43 , Brady Duga <duga@google.com <mailto:duga@google.com>> wrote: >> >> Local and remote instead of packed and unpacked? > > Doesn't the same issue arise as with online vs. offline? I can have, on my laptop, the same document side-by-side in a package (say, an EPUB file) as well as part of my directory structure. They would be both 'local', wouldn't they? > > And they might both be EPUBs. The requirement to zip the archive didn't always exist, and may not in the future. Traditionally, the concept of a "document" in markup languages did not imply one file. If we are changing that we should *definitely* stop using document in our terms! In fact, knowing if something is in one file or not is difficult. On OS X, there are documents that are shown with a single icon and act to the user as a single file, but are actually stored as a collection of files in a directory. A typical user will think it is one document. On Windows you used to be able to open zip files like folders. To the typical user that one file was multiple documents. And, to take that example, Apple actually burned their finger a bit with that one: for Pages and friends they abandoned the one file approach for a Pages document in Maverick, but it created too much problems exactly for the reason you quote (it was not clear to many whether it was one file or a file system, and many tools fell on their face) so, in Yosemite, they packaged the files into one file again. (Zip-based, I believe). I am not really sure where you want to go, I must admit. Do you say that there is no reason to make a difference between a Document being packed into one file (ie, a package) and a Document being spread over files on the file system? We know there is a difference and user agents have to behave differently when they hit one or the other… We did hear at the F2F in NY that there *is* an importance in the publishing world to be able to handle a Document as one single file/entity/unit. The 'packed'/'unpacked' was meant to grasp this difference. (As I said, I am not sure that it is worth keeping the 'Cached' as a separate term.) Can you explain? Thanks Ivan > > >> The use of "one unit" is odd, since presumably you could have a PDD that is in several files, spread across multiple folders. What is the unit it was packed into? > > Hm. I must admit that, for me, a packed PDD is in one file. Just like EPUB, in this sense. Do you have an example of a packed PDD spreading across multiple files? > > See above, but EPUB might be one such example. It depends if we reinstate the virtual file system stuff in OCF and allow for a file system representation in addition to a ZIP archive. > > >> >> As for the term User Agent, EPUB intentionally uses Reading Systems to avoid confusion with a browser UA. A Reading System uses composition (has-a) instead of inheritance (is-a) as the relationship to a UA. It may not be quite technically correct, but it makes clear that a RS may be more than a local browser (it includes any polyfills, server components, etc). > > It was my mistake to bring in another term in the discussion, my apologies. Brady, is it o.k. if we postpone this discussion (the term is on the list of pending items on the Glossary page) or we push it into a separate thread? I am a little bit afraid of mixing up discussion that would make things very messy. > > I am fine not adding a new term, and for our work User Agent makes sense. I was just trying to explain why Reading System exists. I don't think this group should use that term. ---- 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
Received on Tuesday, 15 September 2015 14:12:38 UTC