Digital Publishing Interest Group Locator Task Force call

Bill_Kasdorf: I did not realize :)

... the doodle poll to set the meeting time for the task force
... we'll likely pick 15UTC on Mon or Wed

ivan: for Wed call, we have WG with charter until Feb
... by early Feb, that group will close

Bill_Kasdorf: Wed sounds like best date
... should we go with that?
... 10EST Wed it is

ivan: probably not this code; I'll set up a separate call

(administrivia)

Bill_Kasdorf: anyone who wants to sign up for the task force can do so
... I have not prepared thoughts on chairing this
... Tzviya said we should pick up where we left off last time
... there was discussion on list

ivan: I sent an email before xmas

<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0144.html

ivan: about this question whether we need symbolic links to handle this
... what the URL of a constituent of a PWP is
... Daniel remarked, is this whole issue a red herring?
... do we know what a URL is for a PWP
... this is the web
... there may be good habits
... but in general we may not have an issue
... I'm not 100% convinced

Bill_Kasdorf: I was persueded by that
... the issue of changes to a PWP, does the locator change?
... does adding an anno make it a different PWP, and then changes the location?
... it may not be possible for us to specify the locator
... we still need to address syntax of component

ivan: the question w/ daniel is the 2nd thing, not the first
... the pwp has a locator, whatever it is
... the question is what is the URL of the elements of a PWP

<tzviya> see Daniel's note https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0163.html and Cool URIs don't change http://www.w3.org/Provider/Style/URI

ivan: the question of change is a different question
... do we have to deal with this or not?
... if I handle my website in a UNIX environment on server side
... I may want to use sym links to font file
... I use a local url
... if someone changes where the font is, I can easily update, world doesn't have to know

Bill_Kasdorf: and you can point to that resource from many pwps

ivan: Daniel, you are on the call

Daniel: My thoughts are
... this is a common problem
... on the web
... you'll have to implement things on your server
... or you have some good practice guidelines in place to deal with objects referred to be locators
... I don't think it's a pwp issue
... it's not much different from a complex website
... must use http, etc
... so we don't need to specify a symlink type of thing for pwp
... a manifest might be useful
... to declare the types of resources it needs to be complete
... that's one level of indirection to help with changing urls
... I made a comment about MIME types
... this is more about the reference point into the pwp
... there is an existing mechanism on the web on resolving relative URLs to their base
... this ties into not reinventing the wheel

Bill_Kasdorf: sounds good
... we should still provide practical examples and recommendations
... we shouldn't be reinventing or narrowing existing web specs
... pwp is web content

tzviya: I want to pick up on something daniel said
... I don't think any of us like the symlink idea practically
... this was an issue with packaging for the web, where the visible link changed
... daniel touched on concept of indirection
... being declarative with the manifest can help us with that
... then we have enough info to have a stable URL
... and we don't need changes in the URL

Bill_Kasdorf: I agree, and I think the manifest is the first discussion

mgylling: Daniel, here's a challenge for you
... the pwpwp says what makes pwps peculiar compared to web content is that they exist in two states
... one is online, and one is offline (package, archive)
... that's why we're here
... what happens to the URL?
... someone annotates a pwp online
... the anno is attached to a html url
... then pub is taken offline
... then user wants to resolve anno
... how is that connection maintained?
... we don't want different URLs
... how would this work?

Daniel: "Wether or not we use resources server-side or locally, there's a concept of base HREF that is akin to that of an XML or HTML file."
...: "so it's possible to resolve relative references that can be compared and matched against a target or an annotation. It seems to me that we need a way to define - in the online manifestation of a PWP - a resource (font or image) if it is internal or external - that can be just linked to the fact that there is a top-level folder, or it could be somekind of metadata that defines the base URL

for the PWP. If you have that information, you can map URLs to the offline manifestation."

markus: "We may not want to map back to service workers..."

<DanielWeck> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0163.html

Markus: "When you change the state of a PWP from online to offline you need to manage the base URL"

<DanielWeck> See examples above of URLs for root / base PWP

Daniel: "I'm not convinced it's easy, but I posted a link in IRC, with a comment, there are examples in this that... For example, different types of URLs that could represent the same PWP publication. Not defining what the payload is, but what we're referring to in that publication. Whether it is Index.html or some other item. We can derive from that all the URLs, all the resources contained within that PWP, and all the resources required when taken offline. External fonts wouldn't want to be downloaded (assuming licensing) there may be a different between what is online and offline. Based on the base URLs, it would be possible to determine the absolute URLs when downloaded offline. "

Ivan: "I'm a bit hesitant here because where we seem to go is some sort of a restriction on what a PWP is. In the sense that what we envisage is some sort of local higherarchy of files that consitutes a PWP whereas in the current definition of a PWP, the PWP consists of any kind of resources that are spread all over the web. Even if in practice, even for a certain class, I may have a restriction - i'm uneasy with that restriction. I hate that we have to refer to special services. If I look at the philosophy of service workers (if everything is service workers) the fact that the font is on another server, is immaterial, as the whole process of turning something offline and online can take care of that just as well as if it were a relative URL... I'm a little uneasy about that. If we

think we have to go that way, it's something we clearly have to specify. The reason we have to specify it, is that we have to decide and define it that way."

Ivan: "We may have to go that way, but I feel uncomfortable that way. If we use the technology of service workers - then nothing has to be changed - as nothing needs to be done with the difference of offline and online."

Markus: "So you say we should require service workers?"

Ivan: "I feel uncomfortable, so I'm not sure. But we need to have restrictions?"

Markus: "If you have remote resources on other servers, they have full URLs."

Bill: "Does the manifest have to specify which resources need to be included offline? And which are to be accessed elsewhere?"
... "So it's requiring service workers, or specifying which items are required for offline?"

<dauwhe> NickRuffilo: In html5 offline mode existing spec

<dauwhe> ... there is the concept of a manifest that allows to specify when you're in no-connectivity mode

<dauwhe> ... how should you handle files like something.php

<dauwhe> ... it's possible to in theory repurpose that

<dauwhe> ... take a font living on another server

<dauwhe> ... in offline mode use this font instead

<dauwhe> ... I'm unsure if there's a way in a manifest to say to download a file

<dauwhe> ... what could be handled through that is a demarcation saying what external resources should be cached locally

<dauwhe> ... when creating a version of the file

<dauwhe> ... if SWs are the thing determining that

<dauwhe> ... I guess that's a possibility

<dauwhe> ... it puts more onus on the creator of the PWP

<dauwhe> ivan: which offline spec are you referring to

<dauwhe> NickRuffilo: html5 application cache

<dauwhe> tzviya: which SWs are meant to replace

Charles: "Markus was bringing up Annotations online/offline - and having a Base URL. Do we really want a base URL? What if there are two versions each on different servers. It's all about where the relevant things are."
...: "if you are on server A, the information is there. If you are on your local filesystem, then it's there... Or am I missing something?"

Markus: "Lets not go down the rabbit hole of annotations and the link. Sometimes you want the equality respective of location and sometimes you do not. it's the aspect of the social nature of the problem. We're not solving that problem here, the annotations group is."

daniel: "I was going to take on 2 topics - to come back to markus's thought exercise. From symbolic linking to a use-case, we have annotations that may be linked to additional PWP publications, what does it mean when they become an offline object that can be transfered. Markus just answered that, so I won't go down that path, but the second topic is - perhaps we need to clarify what an offline manifestation is. I hear quite a bit about service workers - BIT which will help us achieve that behavior. My experience as an implementer, and based on epub3 usage. The way I envision a PWP is a (zip) file implementation that's created by a server that is able to provide the file that can be put on to a file system or a USB device, etc, so it can be transfered to a different browser session

...: "There is session information that is held in the browser itself.... If I have a zip file with a manifest that has the offline/online information, how do I handle something like annotations?"

Bill: "When you say zip...."

Daniel: "I mean a tree of files - doesn't matter if it's zip, tar, etc."

Ivan: "Yes - a tree of files - thats what I was referring to. Do we restrict PWP to be a tree of files, or not?"
... "If we do restrict, the situation might become much simpler. You can do all sorts of things with URLs. The current spec of PWP does not make this sort of restriction. It's something we have to decide. There is one more aspect of the discussion that bothers me. Up until now, the idea that we have that the reader or the browser handles the URLs of a PWP is just the one that is used today there is no extra work in it. It just works the way it does now. If we begin to manipulate things via the manifest (if the font is remote, the manifest will tell you, something needs to be done) that means that when I manage files in a PWP, the browser or reader needs to do something special - such as interpret the manifest. That is an extra load that I'd love not to have to have. It's a restriction that if we need we have to specify."

Bill: "Ivan - when referring to this tree of files, am I right in thinking the components of that tree can be an external file that is referenced by links?"

Ivan: "An external file is not part of the tree - it's somewhere else."

Tzviya: "That goes back to the question - where does the manifest fit in and what is the value of it. We can have an abstract tree - and the manfiest can help with that. If it isn't part of the package, how are we reaching across servers for this? Is that part of our abstract tree?"

Ivan: "We're getting back to symbolic links - the interactions then are hidden somewhere."

Bill: "The reason I raise that point of clarification, is that it's fundamental to what we're trying to do. What we're trying to do... In some cases a fallback mechanism is used - publishers will want a way to specify that. "

<dauwhe> NickRuffilo: I have a counter-question

<dauwhe> ... can you have an offline file

<dauwhe> ... that is actually abstract

<dauwhe> ... is that possible

<dauwhe> ... I want to download something to my kindle

<dauwhe> ... I get the PWP on there and i want to read it

<dauwhe> ... is it even possible to have an online resource

<dauwhe> ... is it possible to have full document that's complete?

<dauwhe> Bill_Kasdorf: or I don't want to pay for wifi

<dauwhe> NickRuffilo: if we have an answer on that, great

<dauwhe> NickRuffilo: I'll back off from the queue and send an email

Charles: "I like the idea of a fallback - you could simply be offline - DNS issues, connectivity, etc, if you're offline temporarily... A temporary offline situation should be handleable."

Bill: "We keep circling back to the manifest. The indirection and the manifest..."

Ivan: "Not invalidating anything that was said, we have to be very careful - one of the big differences between the web and the hypertext systems that were being built in the 90s, is that people wanted a full consistency of everything all the time. They got into a very complicated settings that everything was there. One of the reasons why the web was built was the recognition that sometimes things go wrong - but there is a simplicity. We may have to deal with fallbacks but we have to see how far we actually want to go with that."

<HeatherF> Gotta drop off. Intense call, thanks!

Dave: "We're talking about all these issues with remote resources - in some sense that's the document author's or programmers job. What should happen if I'm offline... Service workers are an answer to that. Unlike appcache, it gives you total control over those situations. Our bigger concern is how to handle remote resources is security and cross-browser issues. That is the sort of thing that worries me. I think we have all the capabilities to do these things. We only have 2 minutes left."

Daniel: "If the CDN crashes, or I simply need a a fallback, there are existing CSS items that allow for fallbacks on fonts. That would be the easiest way to deal with things like that. The last comment - going back to what Ivan said - what makes the web great is that it has graceful degredation, and deals with failure. I think we need to make sure that the offline version is as robust as possible, but leverage the existing online."

Bill: "What about the next meeting?"
... "Should we pick up the conversation on wednesday? Then back to Tzviya and Markus with the next epub meeting"

Ivan: "I am almost sure I can't be on the meeting..."

Bill: "The first locators meeting could be the 13th..."

Tzviya: "I think it's OK to hold the meeting until the 13th, but lets keep the conversation going via the email list. We do have a deadline."

Bill: "Agenda for the meeting on the 11th?"

Tzviya: "... We'll get back to you..."
...: "keep convo going over email"

<DanielWeck> Bye!

bye!