Digital Publishing Interest Group Teleconference

29 Feb 2016


See also: IRC log


Tzviya Siegman, Dave Cramer (dauwhe), Brady Duga, Bill Kasdorf, Deborah Kaplan, Ben De Meester (bjdmeest), Leonard Rosenthol, Tim Cole, Romain Deltour (rdeltour), Charles  LaPierre, Nick Barreto, Heather Flanagan, Ivan Herman, Markus Gylling (mgylling), Peter Krautzberger, Chris Maden, Ayla Stein (astein), Daniel Weck, Liam Quin, Bert Bos, Nick Ruffilo
Vlad Levantovsky, Luc Audrain, Alan Stearns


<tzviya> https://www.w3.org/2016/02/22-dpub-minutes.html

Tzviya: "First up - approve minutes from last week"

Dave: "Work of art. "

Tzviya: "Minutes approved"

<pkra> good to have that on record!

<tzviya> https://github.com/w3c/dpub-pwp-loc

Tazviya: "Update from locators task force. There's a link to the WIKI in the agenda (and now in the minutes)"

Locator TF

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."

<bjdmeest> http://book.org/1/

<bjdmeest> http://publisher.com/books/1.pwp

<ivan> Two additional 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

...: "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..."

<bjdmeest> http://publisher.com/books/1

<bjdmeest> http://publisher.com/books/1/
...: "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"

<bjdmeest> Metadata: manifest + http://publisher.com/books/1.pwp http://publisher.com/books/1/
...: "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 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.

...: "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."

Ivan: "Let me try to complement 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 all the complexity from that from whatever does the rendering This is an abstraction that is important and could be done by service workers but that's beside the point."

...: " 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 is set up."

<ivan> https://github.com/w3c/dpub-pwp-loc/blob/gh-pages/drafts/PWPClient.png

...: "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 - regardless of how the server is set up. These are additional points."

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 interact. Ivan's picture is a good one that goes through many options. "

Tzviya: "Other questions?"

Markus: "Where does the difference between locator and identifier occur?"
...: "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 colleague, right?"
... "Is that an issue or we get all that bonus identifier stuff for free? Or are you trying not to go there?"

Ivan: "An identifier and a locator may be identical but may not be. Identifier may be a URN - 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 be a differently owned things (a new cannonical locator) or does it keep the identifier and keep a reference from your locator."

...: "We use the term breadcrumbs on that. A locator refers to a specific instance, whereas an identifier refers to something larger. "

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. "
...: "we've looked at annotations as an issue, but we've looked if the commented version is the same as the uncommented version.

Tzviya: "What are the next steps for this group?"

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."

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."

Markus: "Is it in the groups scope to define the PWP processor rules for reverse engineering a full URL for a resource?

Ivan: "I'm not sure what you're asking?"

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?"

Markus: "yes"

Leonard: "yes, it's in scope - we should define the steps, but not the code itself."

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?"

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 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."

Charles: "I was wondering has their been any work in an accessibility work?"

Tzviya: " I think that's non-specific to the locators discussion"

Charles: "If you are dyslexic or need something special, do you need a special locator for something like that?"

Ivan: " Sometimes you may need a different font - which means for that profile, you need some additional URL mapping that needs to be done. "

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."
... "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."

Bill: "My perspective is that 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, accommodating, non-prescriptive standard. Many things like ePub are very prescriptive - if you want to use this, you need to do this."

...: "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."

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 that's 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."
... "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. "

Tzviya: "Next steps..."
... "Ben - a summary with some action items at the end?"

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."

Tzviya: "We can all agree to the next topic"


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."

Dave: "I agree..."

<pkra> private use area

<pkra> of Unicode.

<pkra> hah

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."

Peter: "If you wanted to do something, you could talk to UNICODE people."
..: "In mathematics there are quite a few things that haven't been addressed... And there are things beyond what MathML will provide..."

Tzviya: "Klingon is a great example of what should not go in unicode and should be in PUA."

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 different ways for things to be represented on browsers. What's in scope for css in the question..."

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."

<pkra> many people disagree with "it's clear that math layout should be in CSS"

<pkra> (not me, but just saying, lrosenth :)

<lrosenth> @pkra - understood…

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 Gods of W3C (Ralph and Philippe). 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 math on the web - from a bottom up manner. 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...

...: "Whether the syntax is MathML or LaTeX is besides 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 during TPAC. This is something that would work for math, but it would work for other areas as well. Math has probably the most mature set of implementers/practitioners/landscape... It's more up-to-date solve to  this problem. It was literally just before this meeting, but this is where we want to go. "

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."
... "We're getting reps of MathJax... Peter won't be able to make it, but there will be other representatives. "

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."

Liam: "Exciting to see more initiative. But - it is just another initiative that we're doing - do we have any browsers involved or implementers?"

DavE: "If Mozilla says they're part of supporting science on the web, well, this is science!"

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

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 a lot 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. "

Tzviya: " What kind of examples would you recommend sending? Most people I work with say that MathJax covers it."

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."

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."

Peter: "I'm not sure what this group should do. But when it comes to the new possible group - and it's full of implementers, we could discuss and be useful to hear about the content side"

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 approach?"

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. "

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 miseries of the world"

<pkra> +1

Bill: "My instinct is to focus on math, then look for other use cases"


Bill: "Solving this for math ALSO solves it for others..."

Tzivya: "Sounds like the focus needs to be on layout - which is a very broad issue."

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..."

Tzviya: "Yes, but we wouldn't bring that to the CSS working group."
... " 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."

<pkra> +1

<Bill_Kasdorf> 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

Tzviya: "We're at the end of our time - thank you everyone"

<ivan> trackbot, end telcon

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/03/01 08:06:32 $