15:54:40 RRSAgent has joined #dpub 15:54:40 logging to http://www.w3.org/2016/02/29-dpub-irc 15:54:42 RRSAgent, make logs public 15:54:42 Zakim has joined #dpub 15:54:44 Zakim, this will be dpub 15:54:44 I do not see a conference matching that name scheduled within the next hour, trackbot 15:54:45 Meeting: Digital Publishing Interest Group Teleconference 15:54:45 Date: 29 February 2016 15:55:24 brady_duga has joined #dpub 15:55:52 NickRuffilo has joined #dpub 15:56:54 present+ Tzviya 15:57:18 present+ 15:57:35 Bill_Kasdorf has joined #dpub 15:58:05 TimCole has joined #dpub 15:58:10 present+ duga 15:58:18 agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2016Feb/0160.html 15:58:47 ScribeNick: NickRuffilo 15:58:53 scribenick: NickRuffilo 15:59:16 present+ Bill_Kasdorf 15:59:30 bjdmeest has joined #dpub 15:59:38 lrosenth has joined #dpub 15:59:39 present+ Deborah_Kaplan 15:59:43 Regrets+ Vlad_Levantovsky, Luc_Audrain, Alan_Stearns 15:59:55 present+ Ben_De_Meester 15:59:55 mgylling has joined #dpub 16:00:12 rdeltour has joined #dpub 16:00:13 present+ Leonard_Rosenthol 16:00:13 present+ Tim_Cole 16:00:37 clapierre1 has joined #DPUB 16:00:45 present+ 16:00:46 Present+ Charles LaPierre 16:01:04 present+ nick_barreto 16:01:43 HeatherF has joined #dpub 16:01:50 present+ Heather_Flanagan 16:02:23 present+ Ivan 16:02:33 present+ Markus 16:02:34 https://www.w3.org/2016/02/22-dpub-minutes.html 16:02:45 present+ Peter. 16:02:45 Tzviya: "First up - approve minutes from last week" 16:02:52 Dave: "Work of art. " 16:02:57 Tzviya: "Minutes approved" 16:03:05 good to have that on record! 16:03:16 https://github.com/w3c/dpub-pwp-loc 16:03:26 Tazviya: "Update from locators task force. There's a link to the WIKI in the agenda (and now in the minutes)" 16:03:30 Topic: Locator TF 16:04:15 Ben: "we as a task force are looking for ways to look up a PWP without knowing what state the PWP is in - packed, unpacked, online, cached - we should be able to locate the same resource using a transparent locator that doesn't need to know the state of the PWP." 16:04:42 astein has joined #DPUB 16:04:51 chair: Tzviya 16:05:04 cmaden2 has joined #dpub 16:05:13 http://book.org/1/ 16:05:18 present+ Chris_Maden 16:05:24 http://publisher.com/books/1.pwp 16:05:34 Two discussion texts: https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/locators.md and https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/ivans-musings.md 16:05:39 ...: "To be able to do that, we need some canonical locator - a URI that points to PWP or a resource of that PWP. At the moment the canonical locator is constructed as if it's online and unpacked - so it's conceptual, so if it ISN'T online, it can still be accessed. For example, if you have a publication, the canonical locator could work on a different domain..." 16:05:58 http://publisher.com/books/1 16:06:01 http://publisher.com/books/1/ 16:06:18 ...: "The easiest case is if the canonical locator co-incides with the PWP. If your publisher would publish the book unpacked, then you could have the URLs above" 16:06:53 Metadata: manifest + http://publisher.com/books/1.pwp http://publisher.com/books/1/ 16:07:43 present+ astein 16:08:03 q? 16:08:16 q+ 16:08:17 ...: "What happens is we get back the PWP's metadata, which gets us the manifest and also a list of all the published states of that PWP. The metadata returned would be the manifest. Once the client has the metadata, the client would do some PWP processing to resolve what the user wants. They could download the PWP and get resources and start reading. This would need server configuration to 16:08:17 return the manifest and link set, but we're trying to make sure that minimal configuration would be sufficient to have a server that can publish PWPs. 16:08:55 ...: "We have quite a few draft documents, and now we need to get some definitions down and the minimum set of configurations so that we can show how to publish a PWP with their locators and the correct functions of the server and the client." 16:09:06 ack iv 16:10:21 q+ 16:10:46 Ivan: "Let me try to compliment what ben said. There are 2 things that are important. During the discussion we used the abstraction of a PWP processor in many respects, the PWP processor tries to abstract... A PWP processor is a client-side thing that takes care of all these translations among the various URLs and locators, and hides lal the complexity from that from whatever does the rendering 16:10:46 . This is an abstration that is important and could be done by service workers but that's beside the point." 16:11:33 s/lal/all 16:11:46 ...: " the other important thing here is that the way we try to decide who does the processing - in terms of it gets the data and processes them. A little my view - and not everyone may agree - is that it should be done in a way completely independent in how the server is set up. If we get to a more formal way that the server is set up - the only thing we'd have to specify is the way the client 16:11:46 is set up." 16:12:37 https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/PWPClient.png 16:13:02 ...: "We had discussions about whether a server set up that relies on content negotiation - some think it's a bad idea, some think it's a good idea. It's a choice of a specific setup that we do not need to specify. We should not say that the server must use content negotiation. I did a drawing - that hasn't yet been approved by the group - about what needs to happen on the client side - 16:13:02 regardless of how the server is set up. These are additional points." 16:13:04 ack lr 16:14:21 Leonard: "I don't disagree with anything you've said. I would like to add: to express that there are 2 types of PWP processors - either smart or 'dumb' One client-side and one server-side. What Ivan is getting at is that the agreement is that there is disagreement as to whether the intelligence should be on the client or the server. Regardless of what's on one side, we want the other side to 16:14:21 interact. Ivan's pciture is a good one that goes through many options. " 16:14:24 q? 16:14:27 q+ 16:14:29 ack mg 16:14:34 Tzviya: "Other questions?" 16:14:49 Markus: "Where does the difference between locator and identifier occur?" 16:14:51 q+ 16:15:35 ...: "Assuming this is deployed, and I'm only with a reading device with self-contained publications and no server - if i have this, i can still annotate my local publications. When I get back online- share them with the colleage, right?" 16:15:41 q+ 16:16:00 ack iv 16:16:00 ...: "Is that an issue or we get all that bonus identifier stuff for free? Or are you trying not to go there?" 16:17:46 Ivan: "An identifier and a locator may be identicial but may not be. Identifier may be a UIN - which may not be referenced. In this sense they are already different. A locator is a URL. the setup works with what you say - when you have a logical instance of a book that you own or have the right to do something with. Then it becomes a business issue - if you give me that book, whether it will 16:17:46 be a differently owned things (a new cannonical locator) or does it keep the identifier and keep a reference from your locator." 16:18:27 ...: "We use the term breadcrumbs on that. A locator refers to a specific instance, whereas an identifier refers to something larger. " 16:18:27 ack lr 16:19:14 Leonard: "I wanted to add, we have not been, in the locator group - been talking about identifiers, we've been talking about locators. that has not been our goal. How do we locate this thing and all it's associated resources if it's packed, unpacked, online or not - that's what we've been focused on. " 16:19:41 q? 16:19:58 ...: "we've looked at annotations as an issue, but we've looked if the commented version is the same as the uncommented version. 16:20:06 Tzviya: "What are the next steps for this group?" 16:20:44 q+ 16:20:48 Ben: "I think that as we are in agreement that we have to specify and make everything a little bit more... written down so we can go on to the next step. The diagram with ivan - that we agree more and more with the details and spec this out a bit. So we have a complete document for this." 16:21:32 ack mg 16:21:37 Ivan: "It always helps by taking all these things and write down in a spec what we can clearly identify the open issues, where we will go for it, etc. Whether all the info will flow back to the PWP document, we will see. That may be the end result, but for now we need to have a proper writeup." 16:21:38 Daniel_Weck has joined #dpub 16:22:01 q+ 16:22:01 Markus: "Is it in the groups scope to define the PWP processor rules for reverse engineering a full URL for a resource? 16:22:13 Ivan: "I'm not sure what you're asking?" 16:22:18 Markus: "Uhh..." 16:22:24 ack lr 16:23:03 Leonard: "Are you asking - given a relative URL or one related - is there a canonical set of processes where the PWP process can determine the resource within?" 16:23:05 Markus: "yes" 16:23:17 present+ DanielWeck 16:23:23 Leonard: "yes, it's in scope - we should define the steps, but not the code itself." 16:23:30 q? 16:24:13 Markus: "The local resources are descendents - but PWP doesn't constrain to local resources - such as an item that lives on another server. We'll need rules just for clarity on that factor, no?" 16:24:33 q+ 16:25:59 q+ 16:26:10 ack cl 16:26:11 Ivan: "That part we did not discuss. For the time being what we discussed with relative and absolute URLs was the model of having everything out there like a tree. Whether we would add an additional layer of URL translations, into the metadata that the processor would have to manage is a bit sideways to the locator discussion. Here is a mapping table, and the reference hits this URL so we go 16:26:11 over there - we haven't discussed that. I would prefer at this point to postpone that discussion. Not that we should avoid that. Lets discuss the first issues first. Some of the discussion that we're having here would possibly be picked up by the ePub BFF 3.1 work - which has a hierarchical view of the world." 16:26:53 Charles: "I was wondering has their been any work in an accessibility work?" 16:27:02 Tzviya:" I think that's non-specific to the locators discussion" 16:27:47 Charles: "If you are dislexic or need something special, do you need a special locator for something like that?" 16:28:20 Ivan:" Sometimes you may need a different font - which means for that profile, you need some additional URL mapping that needs to be done. " 16:28:40 Leonard:" There may be some confusion about remapping locators - and while we could use the same technology, I think it would be the wrong use of it." 16:28:40 ack lr 16:28:41 q? 16:29:25 q+ 16:29:31 ack bill 16:29:32 Leonard: "I wanted to go back to something ivan said - I know there are some people looking at the work of the locators groups - such as the epub BFF work. There are others of us that are not trying to align it with any other piece of work, and are simply concerned of it as the long-term approach. If it works out - great - but that isn't the intent of the group." 16:29:41 q+ 16:30:48 Bill: "My perspective is taht these groups need to pay attention to what they are doing to avoid conflicts/issues. Leonard's basic point is that on the PWP side, it needs to be pure web-standard anything you can do on the web. This is why I've often made the point that PWP needs to be a broad, accomodating, non-prescriptive standard. Many things like ePub are very perscriptive - if you want 16:30:48 to use this, you need to do this." 16:30:52 present+ Liam_Quin 16:31:42 ack iv 16:31:45 ...: "I see what we call an epub - to be a profile - a certain type of PWP - but it's not exactly the same as a PWP. it puts requirements on accessibility and other specifications such as whats happening in the education space. The general overarching PWP spec shoudln't/doesn't restrain." 16:32:55 Ivan: "We don't have a disagreement here. We know that the epub working group and the BFF is looking at this work as a possible solution. I know thats the case, and I think that's a proper way of operating to keep that as an element. The fact that PWP iteself is general is good." 16:33:34 Ivan: "Having future epub being a subset of PWP - that's an avenue we'll have to discuss, but at the moment, it's not on the agenda. " 16:33:52 Tzviya: "Next steps..." 16:34:14 Tzviya: "Ben - a summary with some action items at the end?" 16:35:02 Ben: "I'd like to review ivan's diagram on the next call, then we can agree on that and have the summary. Then we can work towards a spec. Next meeting is wednesday." 16:35:09 Tzviya: "We can all agree to the next topic" 16:35:28 Topic: CSS & STEM 16:36:46 Tzivya:" Last week when alan joined us we talked about samples that the group provided to the CSS working group. At the latest houdini they discussed table alignment. One issue we complain about is how difficult things are - but we need examples. We need a captain of examples. Dave has been a great go-between, but not sure it's in your wheelhouse - and not sure you have time." 16:36:51 Dave: "I agree..." 16:37:25 private use area 16:37:30 of unicode. 16:38:02 hah 16:38:04 q+ 16:38:08 ack pk 16:38:11 Tzviya: "We could also just email them to the list and gather them. One example I came up with recently - We use lots of characters in PUA for chemistry - there are characters that denote certain bonds - they are private use items - they are created with custom fonts. It's very messy because they are being defined without a standard." 16:38:21 Peter: "If you wanted to do something, you could talk to UNICODE people." 16:39:03 ..: "In mathematics there are quite a few things that haven't been addressed... And there are things beyond what MathML will provide..." 16:39:05 @ivan - not any longer, tney removed it a while back 16:39:15 q+ 16:39:20 ack Tim 16:39:27 Hadrien has joined #dpub 16:39:28 Tzviya: "Klingon is a great example of what should not go in unicode and should be in PUA." 16:40:17 q+ 16:40:28 can I put Ivan on the queue? 16:40:31 :) 16:41:09 tim: "One of the questions is - what of this can fall back on the current css work with a little bit of effort. Are they ones we want the CSS to solve? I'll default to some of Peter's work on MathJax - sometimes it's easier to have differnet ways for things to be represented on browsers. What's in scope for css in the question..." 16:41:34 q+ 16:41:40 ack lrosenth 16:41:42 q+ 16:41:45 ack lr 16:42:15 ack iv 16:42:18 Leonard: "I think we're getting confused with what belongs in CSS and what belongs in HTML proper. Table/decimal alignment and math layout belong in CSS. When we talk about the semantic nature of chemical equations - we've gone outside of that. MathML, ChemML - how one lays that out may or may not be CSS. We just need to be very careful of the semantics VS layout." 16:42:19 many people disagree with "it's clear that math layout should be in CSS" 16:42:42 (not me, but just saying), lrosenth :) 16:42:52 @pkra - understood… 16:44:23 Ivan: "I wanted to talk about that later. As an absolute coincidence, peter and I were just on a meeting with another math related company - plus the guts of W3C (ralph and philip). we talked mainly about mathematics and not stem in general. Where we ended up is the following: we may want to set up a separate group - community group - and look at the problems around what the heck happened with 16:44:23 math on the web - from a bottom up mannor. Essentially what Leonard just said - what are the features that implementors hit. Some are CSS that could just get tweaked. Some are HTML issues - elements that are missing - and some may be related to ARIA work as they are accessibility issues. Some may be SVG? Some just need a standard... 16:44:42 q+ 16:46:04 q- 16:46:20 ack pk 16:46:22 ...: "Whether the syntax is MathML or LaTeX is beyond the point. That is an approach we may want to take - we'd only need a few paragraphs of a charter. Whether we have a practicality. Then we'd need to look at and see the space before we see where it goes. We could have a mini face-to-face. This is something that would work for math, but it would work for other areas as well. Math has 16:46:23 probably the most mature set of implementors/practitioners/landscape... It's more up-to-date to sovle this problem. It was literally just before this meeting, but this is where we want to go. " 16:46:32 ack cl 16:47:25 Charles: "Something benetech wants to do is to be part of what we did in digital publishing - is do the same thing for MathML - we're trying to get a group of people to work on that. A community group might be the mechanism to do that. We're actually doing a math-sprint at an upcoming conference." 16:47:49 Charles: "We're getting reps of MathJax... Peter won't be able to make it, but there will be other representatives. " 16:48:16 Tzviya: "I'm super-excited about this. Until it gets started, we have a gap to fill. It would be beneficial to get some samples to the working group." 16:48:17 ack lia 16:48:17 liam, you wanted to ask about bvds 16:48:20 q+ 16:48:27 argh - I need to drop off. Sorry! Talk to you all on the list. 16:48:48 Liam: "Exciting to see more initiaitive. But - it is just another initiative that we're doing - do we have any browsers involved or implementers?" 16:49:00 ack pk 16:49:20 DavE: "If Mozilla says they're part of supporting science on the web, well, this is science!" 16:51:44 Peter: "Yes, talking about actual use-cases with CSS is important. The question is on what level you wanted to start. The idea is to be bottom up? Do we go very-very bottom up? Pas efforts have gone wrong - so finding places where the browsers are interested in helping and will help. Not sure if we need to find things that are easy - such as math layout and CSS. There are still a few major 16:51:44 issues where browsers have said they are incompatible with CSS. Which of those will be most fruitful to have a conversation about. On some levels it might be easy. We will need alot of use-cases. Some will come from the STEM side. It will be tricky when talking about alignments, it's important to get people who actually deal with this in web context, which we are at mathjax. " 16:52:15 Tzviya:" What kind of examples would you recommend sending? Most people I work with say that MathJax covers it." 16:53:39 Peter: "I think - especially with what Liam said - it would be important to see what CSS folks and browsers would be willing to solve. Yesterday I saw that Jake Archibald suggested something on the CSS note. They were discussing something that could solve a math issue - but then there are some that are really complex and might not be easily solved." 16:53:56 q+ 16:54:34 tzviya: "I have tons of content that I could note: "I can't do this without Mathjax." I realize chrome will not handle MathML important. Is my first issue alignment - because I can't handle it without tons of issues? Am I waiting for you Peter, or just putting together examples of stuff that's very hard to do." 16:55:09 ack Bill 16:55:11 Peter: "I'm not sure what this group should do. But when it comes to the new possible group - and it's full of implementors, we could discuss and be usefull to hear about the content side" 16:55:55 q+ 16:55:56 regrets+ luc, astearns 16:56:18 Bill: "What is the better approach of the two - it would be useful for some issues that come out of the STEM issue that have value outside of maths... The very same issues you have in math you have in poetry. Is it better to focus on things that have a broader application? Or is it more important to focus on STEM - whether or not it's important for others, it's critical for stem. Which 16:56:18 approach?" 16:56:27 ack pk 16:57:33 Peter: "I would like to be supportive of what bill said - it's actually crucial to stop talking about Math Layout and just talk about layout. For example, multiscript is only doable in MathML - but it's really just a simple layout problem that has nothing to do with mathematics. There are bound to be use-cases that are more generic. " 16:57:55 Ivan: "I'm always careful with something like that. We have to concentrate on one area - otherwise we get into a group that tries to solve all the myster of the world" 16:57:58 q+ 16:57:58 +1 16:58:15 Bill: "My instinct is to focus on math, then look for other use cases" 16:58:17 q- 16:58:19 +1 16:58:32 Bill: "Solving this for math ALSO solves it for others..." 16:58:39 q+ 16:58:43 ack pk 16:58:47 Tzivya: "Sounds like the focus needs to be on layout - which is a very broad issue." 16:59:29 Peter: "Semantics is much more important. Layout is basically solved. We have tools for laying things out on the web - but the semantics - especially for math - is a crucial problem. MathML is the only solution. it would be something to bring to the ARIA group..." 16:59:40 Tzviya: "Yes, but we wouldn't bring that to the CSS working group." 16:59:42 regrets+ vlad 16:59:52 present+ 17:00:15 Tzviya:" What we need to come up with is what the CSS working group can help us with - as they have come to us asking how they can help." 17:00:24 +1 17:00:32 on the alignment issue, there are specifics that are shared by math, poetry, and financial statements--the latter being a use case more folks may consider important 17:00:33 q? 17:00:40 Tzviya: "We're at the end of our time - thank you everyone" 17:00:49 cmaden2 has left #dpub 17:00:54 clapierre1 has left #dpub 17:00:58 rdeltour has left #dpub 17:01:57 trackbot, end telcon 17:01:57 Zakim, list attendees 17:01:57 As of this point the attendees have been Tzviya, dauwhe, duga, Bill_Kasdorf, Deborah_Kaplan, Ben_De_Meester, Leonard_Rosenthol, Tim_Cole, rdeltour, Charles, LaPierre, nick_barreto, 17:02:00 ... Heather_Flanagan, Ivan, Markus, Peter., Chris_Maden, astein, DanielWeck, Liam_Quin, Bert 17:02:05 RRSAgent, please draft minutes 17:02:05 I have made the request to generate http://www.w3.org/2016/02/29-dpub-minutes.html trackbot 17:02:06 RRSAgent, bye 17:02:06 I see no action items