- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 1 Jun 2015 18:07:07 +0200
- To: Brady Duga <duga@google.com>
- Cc: Nick Ruffilo <nickruffilo@gmail.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Ralph Swick <swick@w3.org>
- Message-Id: <C8FC951A-5152-4163-82DF-2EB2F3B67355@w3.org>
> On 01 Jun 2015, at 16:58 , Brady Duga <duga@google.com> wrote: > > If there is no package file, do these problems still exist? It seems like that is mentioned in the original email, but I am not sure if any of these cons apply to it. Well, all cons and pros were around my single question: what is the 'canonical' URI for a specific section of a specific chapter in a publication? How would one create an annotation on that section that would also work if I dump the online 'logical' entity into a real physical package, or vice versa? Maybe the answer is: there is no such canonical URI. But I am not yet at the point where I would say that… Ivan > > On Mon, Jun 1, 2015 at 7:12 AM Nick Ruffilo <nickruffilo@gmail.com> wrote: > What if we leave it up to the client/server to determine what the root of the package is and handle it approrpiately? > > So, an epub-web object (or whatever we call it) might live at : //my/item/awesome.epub > > To address a specific FILE in that, you go to //my/item/awesome.epub/text/chap2.html > > To get to a fragment, you just use # in reference to whatever the fragment is: > //my/item/awesome.epub/text/chap2.html#first_header > //my/item/awesome.epub#SomeCrazyTextRangeIdentifier > > If run on a server, it would be the server's job to extract the appropriate package files (when thinking about epub, the OPF for example) and provide that to the client, who can then determine the resources it needs and request them from the server. > > When run LOCALLY, the client will simply extract the package files directly. Otherwise there is no duplication of work or resources, etc. > > There was a note about the fragment (things after the #) not being sent to the server. If that is truly the case - and not just that the server ignores it - a DIFFERENT marker - what - i have no idea... > > -Nick > > On Mon, Jun 1, 2015 at 6:22 AM, Ivan Herman <ivan@w3.org> wrote: > Hi all, > > my sincere apologies for the length of this mail, but I thougt it would be worthwhile to get some issues written down to clarify our discussions... > > On the F2F meeting I made the claim that the identifier/fragment issue may be the most tricky one facing us around EPUB-WEB. I thought it is worth writing this down; maybe somebody can also prove me wrong that this is not such a complex issue after all. Actually, what is below is a summary of a very short email/personal discussion Markus, Tzviya, and I had on the matter after the F2F. (At some point it is probably worth writing down the conclusions of this thread somewhere on the wiki.) > > With that, here is where I see a real problem. > > Let us consider a Packaged Document. The URL of this document is http://www.example.org/doc. The document includes, among others, chapter 2 in file chap2.html. This has a section whose ID is 'sec' (for the sake of simplicity, I consider here the simplest and best known fragment used in an HTML file, ie, using the @id attribute on a, say, <h1> element). The question arising is: what is the full URI for that section? Or, to be more exact, what is the full, *canonical* URI for that section, ie, a URI that is independent on whether the document is off-line or on-line? > > An Aside: How do URI-s work? > ---------------------------- > > Tzviya told me privately that not everyone on the group may know how exactly URI-s and fragments work in browsers and on the Web. So maybe just a few words may be relevant here. If you know this, my apologies, you can just skip this part. > > A URL consists of, roughly, two parts: > > - A "primary" address that identifies the resource somewhere on the web. Say, 'http://xyx.example.com/mydoc' > - A "fragment", that is added after the '#' sign, which identifies something *within* the resource; say, 'mysection' > > There are two steps in handling this to take into account: > > - There can be *only one fragment id in a URL*, ie, only one occurence of '#'. What is after the '#' is interpreted in accordance with a corresponding specification that is bound to the media type of the resource > > - A Web browser interprets the fragment locally. Ie, if it gets 'http://xyx.example.com/mydoc#mysection' it > 1. strips the fragment > 2. it issues a request, through the HTTP protocol, for '/mydoc' to the 'http://xyx.example.com' server > 3. it gets the full resource and then uses the fragment (i.e., 'mysection') to identify something within the returned resource. > > > What is the URI with fragment for section 'sec' in a package? > ------------------------------------------------------------- > > (For the sake of this discussion I refer to the way the packaging specification works in terms of fragments.) > > 1. If http://www.example.org/doc refers to a real, physical package on the Web, accessing 'sec' chap2.html, using the current fragment specification in the packaging document, would be: > > http://www.example.org/doc#url=/chap2.html;fragment=sec > > meaning: > 1. The client retrieves the package http://www.example.org/doc > 2. Unpackages the package in a local cache (or equivalent) > 3. It interprets the fragment 'url=/chap2.html;fragment=sec' by (per the current specification of packaging) by > 3.1. identifying the 'part' within the package, yielding 'chap2.html' > 3.2. 'chap2.html' is an HTML file; because the server knows how to identify something within the file with a fragment, ie, it gets to section 'sec' > > It is important to realize that, in this model, the 'unpackaging' is done by the client (the browser i.e., the reading system) > > 2. If the package is just 'virtual', ie, all documents are on the Web, then there is of course a much simpler approach. The URL of the section is > > http://www.example.org/doc/chap2.html#sec > > meaning > 1. The client retrieves the HTML document http://www.example.org/doc/chap2.html > 2. It knows how to identify something within the HTML file with a fragment, ie, it gets to section 'sec' > > > Back to the original question: what is the 'canonical' URI with fragment? > ------------------------------------------------------------------------- > > It should be one of the two above. However, both have issues: > > A. http://www.example.org/doc/chap2.html#sec > > Pro: this is the 'natural', Web way. > > Con 1: *if* the document is, in fact, a real package then there are two possible approaches to handle this: > > Con 1.1: The *server* handles the unpackaging. Ie, it should be in position to analyze the URL it receives, realize that there is a 'package' in between and do an unpackaging. What this would mean is that the client would have to make requests for all chapters separately, which is not optimal (although it can of course be cached)/ > > Con 1.2: The *client* handles unpackaging. This would require a different server-client protocol, namely: > 1. The client issues a request to 'http://www.example.org/doc/chap2.html' > 2. The server returns 'http://www.example.org/doc/' as a package instead of the original chap2.html file (ie, the server should know that this is part of a package through some redirection) > 3. The client should then unpack and locate the chap2.html file in the package > 4. the fragment should be identified and handled. > > Steps 1-2-3 is not the current practice on the Web in terms of Web Architecture: a client does not 'decompose' the 'primary' part of a URL (beyond separating the server's identification from the part within that server). It is unclear whether changing that is a viable/acceptable for the browsers, and for the overal Web Architecture; it certainly requires a discussion with the TAG. > > Con 2: If the URL is, in fact, a file:///... type one, this means that, for that case, the unpackaging must be done on the client. Ie, there may be duplication of functionality with the server and the client, which is not optimal. > > B. http://www.example.org/doc#url=/chap2.html;fragment=sec > > Pro: this works for a package. > > For a document on the Web, it may also work if there is a 'conceptual' entity on the Web for the document. I.e., http://www.example.org/doc returns some sort of an information to the client that this is, fact, a 'virtual' package, and then the server can issue a new request to http://www.example.org/doc/chap2.html and take it from there. > > (Note that, regardless of the original issue, having a 'conceptual' package handle for a document may not be a bad thing!) > > Con: The URL form is (much) more complex, and may be in danger of being ignored for documents that are on the Web only. > > Personally, I do not have a clear solution in my head. Hence this mail, trying to see how we can move on... > > Let me also add another remark, coming originally from Tzviya, just to add it to the mix: "We need to think about situations such as multiple authors creating one package or peer review (one or many authors + one or many editors submit article + data set to journal for review. It undergoes peer review by one or many reviewers. Journal rejects the article. Something happens to the reviews, and the package is submitted to a second journal) and so on.) In scenarios like this, the concept of versioning and revisioning are a lot more important. It may be covered by OA. I don’t know that we can resolve versioning with an identifier." > > (Again, apologies to be so verbose…) > > Ivan > > > > > ---- > 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 > > > > > > > > -- > - Nick Ruffilo > @NickRuffilo > http://Aerbook.com > http://ZenOfTechnology.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
Received on Monday, 1 June 2015 16:07:21 UTC