15:43:57 <RRSAgent> RRSAgent has joined #dpub
15:43:57 <RRSAgent> logging to http://www.w3.org/2016/01/04-dpub-irc
15:43:59 <trackbot> RRSAgent, make logs public
15:43:59 <Zakim> Zakim has joined #dpub
15:44:01 <trackbot> Zakim, this will be dpub
15:44:01 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
15:44:02 <trackbot> Meeting: Digital Publishing Interest Group Teleconference
15:44:02 <trackbot> Date: 04 January 2016
15:44:45 <ivan> Meeting: locator task force meeting
15:44:50 <ivan> chair: BillK
15:44:58 <ivan> Agenda: http://www.w3.org/mid/09011df719e14ac2a6d8de16ea4b8bbc@CAR-WNMBP-006.wiley.com
15:54:41 <brady_duga> brady_duga has joined #dpub
15:56:20 <clapierre1> clapierre1 has joined #DPUB
15:57:48 <ivan> Present+ Ivan, Dave, Charles
15:58:12 <brady_duga> present+ duga
15:58:39 <dauwhe> present+ Dave_Cramer
15:58:54 <tzviya> present+ Tzviya
15:59:24 <Bill_Kasdorf> Bill_Kasdorf has joined #dpub
15:59:33 <NickRuffilo> NickRuffilo has joined #dpub
15:59:59 <mgylling> mgylling has joined #dpub
16:00:30 <KathyAlley> KathyAlley has joined #dpub
16:01:56 <dauwhe> scribenick: dauwhe
16:02:04 <mgylling> Present+ Markus
16:02:07 <astearns> present+ astearns
16:02:11 <laudrain> laudrain has joined #dpub
16:02:12 <clapierre1> present+ Charles_LaPierre
16:02:13 <NickRuffilo> present+ nickruffilo
16:02:21 <DanielWeck> DanielWeck has joined #dpub
16:02:23 <laudrain> present+ Luc
16:02:29 <DanielWeck> present+
16:02:34 <dkaplan3> dkaplan3 has joined #dpub
16:02:48 <DanielWeck> present+ Daniel Weck
16:02:52 <Bill_Kasdorf> present+ Bill_Kasdorf
16:03:36 <ivan> Present+ KathyAlley
16:03:39 <HeatherF> HeatherF has joined #dpub
16:04:23 <rdeltour> rdeltour has joined #dpub
16:04:27 <dkaplan3> present+ Deborah_Kaplan
16:04:30 <HeatherF> present+ Heather_Flanagan
16:04:32 <bjdmeest> bjdmeest has joined #dpub
16:04:39 <rdeltour> present+ Romain_Deltour
16:04:49 <bjdmeest> Present+ Ben_De_Meester
16:05:45 <dauwhe> tzviya: Bill K. is the chair today
16:06:00 <dauwhe> Bill_Kasdorf: I did not realize :)
16:06:15 <pbelfanti> pbelfanti has joined #dpub
16:06:21 <dauwhe> ... the doodle poll to set the meeting time for the task force
16:07:08 <dauwhe> ... we'll likely pick 15UTC on Mon or Wed
16:07:24 <dauwhe> ivan: for Wed call, we have WG with charter until Feb
16:07:42 <dauwhe> ... by early Feb, that group will close
16:07:52 <dauwhe> Bill_Kasdorf: Wed sounds like best date
16:08:12 <dauwhe> ... should we go with that?
16:08:19 <dauwhe> ... 10EST Wed it is
16:08:33 <dauwhe> ivan: probably not this code; I'll set up a separate call
16:08:56 <dauwhe> (administrivia)
16:09:46 <dauwhe> Bill_Kasdorf: anyone who wants to sign up for the task force can do so
16:10:04 <dauwhe> ... I have not prepared thoughts on chairing this
16:10:15 <dauwhe> ... Tzviya said we should pick up where we left off last time
16:10:26 <dauwhe> ... there was discussion on list
16:10:42 <dauwhe> ivan: I sent an email before xmas
16:10:53 <tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0144.html
16:10:55 <dauwhe> ... about this question whether we need symbolic links to handle this
16:11:04 <dauwhe> ... what the URL of a constituent of a PWP is
16:11:21 <dauwhe> ... Daniel remarked, is this whole issue a red herring?
16:11:26 <tzviya> q?
16:11:28 <dauwhe> ... do we know what a URL is for a PWP
16:11:30 <dauwhe> ... this is a web
16:11:34 <dauwhe> s/a/the/
16:11:41 <dauwhe> ... there may be good habits
16:11:50 <dauwhe> ... but in general we may not have an issue
16:11:56 <dauwhe> ... I'm not 100% convinced
16:12:11 <dauwhe> Bill_Kasdorf: I was persueded by that
16:12:26 <dauwhe> ... the issue of changes to a PWP, does the locator change?
16:12:40 <dauwhe> ... does adding an anno make it a different PWP, and then changes the location?
16:12:59 <dauwhe> ... it may not be possible for us to specify the locator
16:13:12 <dauwhe> ... we still need to address syntax of component
16:13:26 <dauwhe> ivan: the question w/ daniel is the 2nd thing, not the first
16:13:35 <dauwhe> ... the pwp has a locator, whatever it is
16:13:46 <dauwhe> ... the question is what is the URL of the elements of a PWP
16:13:52 <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
16:14:02 <dauwhe> ... the question of change is a different question
16:14:08 <dauwhe> ... do we have to deal with this or not?
16:14:24 <dauwhe> ... if I handle my website in a UNIX environment on server side
16:14:33 <dauwhe> ... I may want to use sym links to font file
16:14:40 <dauwhe> ... I use a local url
16:14:56 <dauwhe> ... if someone changes where the font is, I can easily update, world doesn't have to know
16:15:04 <dauwhe> Bill_Kasdorf: and you can point to that resource from many pwps
16:15:26 <dauwhe> ivan: Daniel, you are on the calll
16:15:36 <dauwhe> Daniel: My thoughts are
16:15:40 <dauwhe> ... this is a common problem
16:15:45 <tzviya> s/calll/call
16:15:46 <TimCole> TimCole has joined #dpub
16:15:46 <dauwhe> ... on the web
16:16:00 <dauwhe> ... you'll have to implement things on your server
16:16:22 <dauwhe> ... or you have some good practice guidelines in place to deal with objects refered to be locators
16:16:30 <dauwhe> ... I don't think it's a pwp issue
16:16:38 <dauwhe> ... it's not much different from a complex website
16:16:43 <dauwhe> ... must use http, etc
16:16:54 <dauwhe> ... so we don't need to specify a symlink type of thing for pwp
16:17:02 <dauwhe> ... a manifest might be useful
16:17:12 <dauwhe> ... to declare the types of resources it needs to be complete
16:17:22 <dauwhe> ... that's one level of indirection to help with changing urls
16:17:35 <dauwhe> ... I made a comment about MIME types
16:17:50 <dauwhe> ... this is more about the reference point into the pwp
16:18:08 <dauwhe> ... there is an existing mechanism on the web on resolving relative URLs to their base
16:18:23 <tzviya> q+
16:18:27 <dauwhe> ... this ties into not reinventing the wheel
16:18:41 <dauwhe> Bill_Kasdorf: sounds good
16:18:53 <dauwhe> ... we should still provide practical examples and recommendations
16:19:07 <dauwhe> ... we shouldn't be reinventing or narrowing existing web specs
16:19:10 <mgylling> q+
16:19:12 <dauwhe> ... pwp is web content
16:19:51 <ivan> ack tzviya
16:20:04 <dauwhe> tzviya: I want to pick up on something daniel said
16:20:16 <dauwhe> ... I don't think any of us like the symlink idea practically
16:20:33 <dauwhe> ... this was an issue with packaging for the web, where the visible link changed
16:20:42 <dauwhe> ... daniel touched on concept of indirection
16:20:50 <dauwhe> ... being declarative with the manifest can help us with that
16:21:12 <dauwhe> ... then we have enough info to have a stable URL
16:21:23 <dauwhe> ... and we don't need changes in the URL
16:21:29 <ivan> q+
16:21:43 <dauwhe> Bill_Kasdorf: I agree, and I think the manifest is the first discussion
16:22:08 <dauwhe> mgylling: Daniel, here's a challenge for you
16:22:31 <dauwhe> ... the pwpwp says what makes pwps peculiar compared to web content is that they exist in two states
16:22:42 <dauwhe> ... one is online, and one is offline (package, archive)
16:22:46 <dauwhe> ... that's why we're here
16:22:52 <dauwhe> ... what happens to the URL?
16:22:59 <dauwhe> ... someone annotates a pwp online
16:23:11 <dauwhe> ... the anno is attached to a html url
16:23:16 <dauwhe> ... then pub is taken offline
16:23:24 <dauwhe> ... then user wants to resolve anno
16:23:30 <dauwhe> ... how is that connection maintained?
16:23:32 <ivan> q-
16:23:45 <dauwhe> ... we don't want different URLs
16:23:54 <dauwhe> ... how would this work?
16:24:31 <ivan> q+
16:24:36 <NickRuffilo> scribenick: nickruffilo
16:24:37 <ivan> ack mgylling
16:24:37 <NickRuffilo> 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."
16:25:52 <NickRuffilo> ...: "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
16:25:52 <NickRuffilo> for the PWP.  If you have that information, you can map URLs to the offline manifestation."
16:25:53 <NickRuffilo> q+
16:26:15 <NickRuffilo> paul: "We may not want to map back to service workers..."
16:26:33 <tzviya> s/paul/markus
16:26:35 <DanielWeck> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0163.html
16:26:40 <NickRuffilo> Markus: "When you change the state of a PWP from online to offline you need to manage the base URL"
16:26:49 <DanielWeck> See examples above of URLs for root / base PWP
16:27:31 <tzviya> q?
16:27:59 <clapierre1> q+
16:29:10 <NickRuffilo> 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
16:29:10 <NickRuffilo> 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.  "
16:29:15 <tzviya> ack iv
16:29:17 <ivan> ack ivan
16:31:19 <DanielWeck> q+
16:31:51 <NickRuffilo> 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
16:31:51 <NickRuffilo> - 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
16:31:51 <NickRuffilo> 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."
16:32:22 <NickRuffilo> 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."
16:32:31 <NickRuffilo> Markus: "So you say we should require service workers?"
16:32:43 <dauwhe> q?
16:32:50 <NickRuffilo> Ivan: "I feel uncomfortable, so I'm not sure.  But we need to have restrictions?"
16:33:11 <NickRuffilo> Markus: "If you have remote resources on other servers, they have full URLs."
16:33:31 <NickRuffilo> Bill: "Does the manifest have to specify which resources need to be included offline?  And which are to be accessed elsewhere?"
16:33:48 <dauwhe> q+
16:33:49 <NickRuffilo> Bill: "So it's requiring service workers, or specifying which items are required for offline?"
16:33:57 <ivan> ack NickRuffilo
16:34:16 <dauwhe> NickRuffilo: In html5 offline mode existing spec
16:34:32 <dauwhe> ... there is the concept of a manifest that allows to specify when you're in no-connectivity mode
16:34:47 <dauwhe> ... how should you handle files like something.php
16:35:02 <dauwhe> ... it's possible to in theory repurpose that
16:35:10 <dauwhe> ... take a font living on another server
16:35:19 <dauwhe> ... in  offline mode use this font instead
16:35:39 <dauwhe> ... I'm unsure if there's a way in a manifest to say to download a file
16:36:06 <dauwhe> ... what could be handled through that is a demarcation saying what external resources should be cached locally
16:36:11 <dauwhe> ... when creating a version of the file
16:36:20 <dauwhe> ... if SWs are the thing determining that
16:36:27 <dauwhe> ... I guess that's a possibility
16:36:37 <dauwhe> ... it puts more onus on the creator of the PWP
16:37:04 <dauwhe> ivan: which offline spec are you referring to
16:37:15 <tzviya> q?
16:37:30 <dauwhe> NickRuffilo: html5 application cache
16:37:40 <dauwhe> tzviya: which SWs are meant to replace
16:38:43 <tzviya> ack cl
16:38:44 <ivan> ack clapierre1
16:38:53 <ivan> q+
16:39:04 <dauwhe> q-
16:39:24 <NickRuffilo> 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."
16:39:46 <NickRuffilo> ...: "if you are on server A, the informatino is there.  If you are on your local filesystem, then it's there...  Or am I missing something?"
16:40:00 <ivan> s/informatino/information/
16:40:35 <NickRuffilo> 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."
16:40:35 <tzviya> ack da
16:42:58 <NickRuffilo> 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
16:42:58 <NickRuffilo> 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
16:42:58 <NickRuffilo> .  "
16:43:42 <NickRuffilo> ...: "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?"
16:43:51 <NickRuffilo> Bill: "When you say zip...."
16:44:09 <NickRuffilo> Daniel: "I mean a tree of files - doesn't matter if it's zip, tar, etc."
16:44:12 <tzviya> ack iv
16:44:37 <NickRuffilo> Ivan: "Yes - a tree of files - thats what I was referring to.  Do we restrict PWP to be a tree of files, or not?"
16:44:39 <NickRuffilo> q+
16:45:22 <mgylling> q+
16:45:27 <mgylling> q-
16:45:30 <mgylling> q?
16:46:50 <NickRuffilo> Ivan: "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
16:46:50 <NickRuffilo> - 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
16:46:50 <NickRuffilo> restriction that if we need we have to specify."
16:47:25 <NickRuffilo> 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?"
16:47:45 <NickRuffilo> Ivan: "An external file is not part of the tree - it's somewhere else."
16:48:43 <NickRuffilo> 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?"
16:49:03 <NickRuffilo> Ivan: "We're getting back to symbolic links - the interactions then are hidden somewhere."
16:49:30 <ivan> q?
16:49:54 <NickRuffilo> 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.  "
16:50:00 <ivan> q+
16:50:00 <tzviya> ack ni
16:50:15 <dauwhe> NickRuffilo: I have a counter-question
16:50:19 <dauwhe> ... can you have an offline file
16:50:24 <dauwhe> ... that is actually abstract
16:50:27 <dauwhe> ... is that possible
16:50:33 <dauwhe> ... I want to download something to my kindle
16:50:45 <dauwhe> ... I get the PWP on there and i want to read it
16:50:54 <dauwhe> ... is it even possible to have an online resource
16:51:06 <dauwhe> ... is it possible to have full document that's complete?
16:51:37 <dauwhe> Bill_Kasdorf: or I don't want to pay for wifi
16:51:53 <dauwhe> NickRuffilo: if we have an answer on that, great
16:51:59 <mgylling> q+
16:53:12 <clapierre1> q+
16:53:48 <ivan> q-
16:53:51 <mgylling> q-
16:54:12 <dauwhe> NickRuffilo: I'll back off from the queue and send an email
16:54:17 <dauwhe> q?
16:54:19 <tzviya> ack cl
16:55:08 <NickRuffilo> 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."
16:55:14 <ivan> q+
16:55:25 <tzviya> ack iv
16:55:26 <dauwhe> q+
16:55:27 <NickRuffilo> Bill: "We keep circling back to the manifest.  The indirection and the manifest..."
16:56:19 <brady_duga> brady_duga has joined #dpub
16:56:48 <NickRuffilo> 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
16:56:48 <NickRuffilo> 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."
16:56:52 <tzviya> ack da
16:57:24 <DanielWeck> q+
16:58:09 <mgylling> ack da
16:58:10 <tzviya> ack da
16:58:15 <HeatherF> Gotta drop off. Intense call, thanks!
16:58:24 <NickRuffilo> 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
16:58:24 <NickRuffilo> that worries me.  I think we have all the capabilities to do these things.  We only have 2 minutes left."
16:59:46 <NickRuffilo> Daniel: "If the CDF 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
16:59:46 <NickRuffilo> possible, but leverage the existing online."
16:59:57 <NickRuffilo> Bill: "What about the next meeting?"
16:59:58 <tzviya> q?
17:00:01 <DanielWeck> s/CDF/CDN/
17:00:28 <NickRuffilo> Bill: "Should we pick up the conversation on wednesday?  Then back to Tzviya and Markus with the next epub meeting"
17:00:37 <NickRuffilo> Ivan: "I am almost sure I can't be on the meeting..."
17:01:08 <NickRuffilo> Bill: "The first locators meeting could be the 13th..."
17:01:34 <NickRuffilo> 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."
17:01:46 <NickRuffilo> Bill: "Agenda for the meeting on the 11th?"
17:01:57 <NickRuffilo> Tzviya: "...  We'll get back to you..."
17:02:08 <NickRuffilo> ...: "keep convo going over email"
17:03:12 <DanielWeck> Bye!
17:03:15 <NickRuffilo> bye!
17:03:27 <laudrain> laudrain has left #dpub
17:03:28 <clapierre1> clapierre1 has left #dpub
17:03:34 <shepazu> shepazu has joined #dpub
17:04:07 <ivan> rrsagent, draft minutes
17:04:07 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/04-dpub-minutes.html ivan
17:11:34 <ShaneM> ShaneM has joined #dpub
18:40:11 <Karen> Karen has joined #dpub
19:15:26 <Zakim> Zakim has left #dpub
19:41:14 <dauwhe> dauwhe has joined #dpub
21:08:38 <shepazu> shepazu has joined #dpub
22:40:04 <dauwhe> dauwhe has joined #dpub
23:04:57 <dauwhe> dauwhe has joined #dpub
23:31:51 <Florian> Florian has joined #dpub