Digital Publishing Interest Group Teleconference

<trackbot> Date: 13 April 2015

I'm sorry Zakim, but I'm not giving up on you. You'll be a real boy soon enough.

<scribe> Scribenick: NickRuffilo

<ivan> scribenick: NickRuffilo

Marcus: "Anyone with objections to approving last weeks minutes?"
...: "Approved."

Aria module discussion

<mgylling> https://rawgit.com/w3c/aria/master/aria/dpub.html
...: "Epub module for ARIA. Link posted in IRC. This was discussed in the previous meeting. State is that the editors are trying to get it to first public working draft."

<mgylling> minutes are here: http://www.w3.org/2015/04/09-aria-minutes.html
...: "we need to have a recorded consensus from both publishing groups. The protocols and formats working group..."

...: "PF discussed the editors job. There were some concerns against it so they have not gotten to a public working draft yet. We'll be discussing this with them for the weeks to come."

...: "Concerns were: Global issue - prefixing of terms for modules such that they end up in different domains. Also a number of concerns in specific terms, such as the 'abstract' term which is well known in books, but also a term used in ARIA for a different purpose. Abstract roles are something that should never be used for content... Identical strings but different meanings."

<Bill_Kasdorf> Just reiterating my minority opinion that I think prefixes are very useful. The abstract example is one of many.
...: "First public working draft isn't expected to be fully complete, or without conflict, which is why we hoped to get there, but it seems these issues need to be discussed before it can get there."

Ivan: "We should see how far we can go and where the breakpoints are"

Bill: "A little bit stronger case: I've always thought that prefixes would end up being necessary. In real-estate what you call an abstract is different from what you call it in books/journals. there are scores of examples of definition conflicts if we don't use prefixes."

Marcus: "The role attribute DOES have a prefixing for definitions"
...: "Based on the RDFA way of doing things. Using the :. The vocabulary basics..."

Bill: "I was also reminded that despite the fact that it isn't used much, the prefixing IS available in the role attribute."

<ivan> role="dpub-blabla"

Ivan: "You say the roll attribute has prefixing using the color. But that's the full domain space, etc. That's a sledge hammer. I thought that you can do something like '[typed above]' is that accepted within ARIA?"
... "it's not a dynamic prefix name."

Ivan: "When they're using namespaces, do they want the obvious sledgehammer or the dash?"

marcus: "It's highly undesirable to have this."
... "Maybe we can raise the question again. If we look at it from a 10-mile high up perspective. If it looks like the W3C wants to support digital publishing, why should things be supported..."

<Karen_> Nick: Coming from a different perspective

<Karen_> …what it sounds like, is we are utilizing certain terms

<Karen_> …for what would be ARIA prefix

<Karen_> …abstract

<Karen_> …we were defining a term in relations to

<Karen_> …a given concept with a limited view space

<Karen_> …so an abstract is a conceptual term that has a solid definition but limited in its scope

<Karen_> …what might be a good idea, and for future groups

<Karen_> …is to take a step back

<Karen_> …and say an abstract is a specific concept of what

<Karen_> …boil down what abstract is…ultimately a summary

<Karen_> …or ultimately a division

<Karen_> …so take a step back

<Karen_> …we might have 16 different definitions for abstract

<Karen_> …and four high-level concepts that we should define terms for

<Karen_> …and lower level ones could be something else, or publishers define them

<Karen_> …but others should be higher level

<Karen_> …at some point digital publishing overtakes physical publishing

<Karen_> …would be great to have terms that envisions those

<Karen_> Markus: That is a very good point, Nick

<Karen_> …it is the way we have been going

<Karen_> …we look up the inheritance chain

<Karen_> …most have a parent

<Karen_> …to go up one step

Markus - "We do need to take a step back and possibly do the more generic term. In the case of 'abstract' we need to look to see if there is a super-class or parent."

Matt: "We need to be weary about saying 'lets just change a term' as that may not yield us the results we like."

Markus: "have to consider things that are not tied to glossary definitions?"
... "To get to the first public working draft we need to have recorded consensus. As for doing call for consesus here, shoudl we do that now?"
... "It feels sudden to discuss now and just vote."

<HeatherF> But this is still a working draft; as you said, it's still ok to have discussion topics

Nick: "I'd like a week to review"

<pkra> + for pushing it. we have a week, no? It also allows the minutes to this call to circulate.

Ivan: "Ideally, the resolution should be taken on a meeting. It's perfectly fine if there is an e-mail discussion between now and next week and if the consesus is done via email. At this moment I'm very - I don't know how to handle it. I can understand that there might be a number of first-class application areas/things from web applications who are just as important - potentially in long term

- may have the same name-clashing problems. "

Ivan: "What I tried is putting the concerns that some people have in the PF working group. They could discuss with us via email as well."
...: "No need to wait for a week when we could have these issues/concerns properly written down and given to us so that we know what we have to answer to. Not only in general discuss but these are the problems."

Charles: "It was mentioned that we don't want the 'role' attribute to say 'dpub-' which treats it as a second class citizen. What is the alternative?"

markus: "The alternative is what we're proposing, where terms are there. A possible solution is similar to what ARIA has done, which is to limit definitions to avoid conflict."
...: "There are two ways to do it, hyphenated and RDFA. What we're saying is that we shouldn't do it for everything, but we should consider it for some."
... "It's complicated. There are pros and cons for everything. In XML there was so much fear of conflict that EVERYTHING became prefixed"

Charles: "If we had something to define - at a global level - to say this is publishing, and everything below is for digital publishing..."

Markus: "There is no such mechanism for roles today."

Ivan: "That gets into religious debate... About roles being able to define profiles... HTML5 declared that to be a dead idea."

<david_stroup> sorry need to drop...

Bill: "Publishers do need definitions, and are using 'class' at the moment, so that they know what it is used for."
... "In the real world, people do use these terms and embed them in their concept."

Markus: "Class is not the only term used, but it is very common."

Packaging examples

<mgylling> https://www.w3.org/dpub/IG/wiki/OCF_Functionality
...: "Next up: Short FYI - Collection of use-cases called packaging. Overview of OCF added.".

..: "This new page lifts the functionality that OCF does. These are the functional hooks."

Ivan: "I went through the text sometime last weekend and there is one question for me that I don't have an answer - if you look at the epub-web and the reason for looking at packaging, it's relatively key to me that if we use the packaging format for web-packaging that we still need to add a super-structure to it for epub-web. Many things used and defined by epub that would migrate to a new

environment. What I would like to understand is the difference between what zip gives me and what web-packaging gives. To compare what is comparable."
...: "Whether ZIP or web-packaging is the best for us is the question for which I don't have a reasonable answer."

Markus: "We still need a fairly exhaustive list of use-cases, then we can start building these comparisons and see what is doable where."

<mgylling> http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_and_Distribution

Ivan: "I did look at the use-cases that Tzviya put up there. I tried to see which could be used by either. That is what I'd like to see more of."

Markus: "Simply put: Next step, once Tzviya - who owns the use-case collection - will be to start doing the comparison."
... "Anything more on Packaging?"

F2F agenda

<mgylling> https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details

Markus: "What we've done is to put the first ... together. If you go down to the schedule area, you'll see we have generous time sessions for packaging, identifiers, pagination and the re-charter."

Nick: "We should discuss outreach/education at the meeting - maybe 30-45 minutes?"

<ivan> +1

<ivan> +10000 to Nick

<Karen_> +1

Markus: "What about STEM?"
...: "Stem at Face-2-face?"

pkra : "I won't be there, but feel free to discuss."

Makrus: "is there a topic you'd like us to be discussing?"

pkra: "I'll have to think about it."

Markus: "We'll finalize next monday. when we hear back from charles and deborah"

identifiers

<Bill_Kasdorf> https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Open_Annotations_Fragment_Selector

Markus: "Next up Bill, updates on Identifiers."

Bill: "We've had productive accumulation of information on the wiki. We have a candidate of specs to consider. [listed a bunch of identifier types]. Ivan added the open-annotations identifier, which I strongly support. I think philisophically aligning the fragment identifier with this annotations model makes all the sense in the world. the reason they are aligning with that is that it's

extremely flexible and it defines a range, not a point. The other ones point to something that is already a defined thing - such as an element. This also allows you to associate a state with an identifier which is very helpful. it accomodates some of the others that have been defined. I'm not trying to force this on anyone, but I'd suggest you look at the options that we have and note there

is a strong case to be made. It is not final though, originated by the open annotations working group."
...: "It's in a working draft. If we think this is the right way to go, we should state that we will align with the way the owrking group is doing the identifiers. it would be nice to keep this moving along but I won't be on the call next week, so not sure if this is something we need to do via e-mail, or am I being too quick to zero-in on the solution."

Markus: "It is not clear to me how the open annotations document has. How can it be translated into a URI? There is no mapping of the concept to URI - at least not yet. For our purposes, it would be important for us to have that."

<Bill_Kasdorf> http://www.w3.org/TR/2014/WD-annotation-model-20141211/#fragment-selector

Bill: "The draft does provide a number of example URIs expressing fragments for a number of different use-cases"

Ivan: "The point is that no, it does not give you a URI. It operates on a different environment because it would express the anchor in terms of an object with various attributes."

<ivan> "selector": {

<ivan> "@id": "http://example.org/selector1",

<ivan> "@type": "oa:DataPositionSelector",

<ivan> "start": 4096,

<ivan> "end": 4104

<ivan> }
...: "So, that is how you define a range selector, but it's not a URI. In this sense it is different from the usual segments."

<TimCole> +q
...: "That is a question we need to ask - is there a way to express those params as a URI"

Tim: "My sense is that there hasn't been much - if any - sense of making that URI. It was defined to be an RDF solution. It's about creating a triple and using those triples to define a fragment."
...: "That said, a couple of these ideas were taking from different communities. so there may be other options/solutions to turning this into a URI fragment."

Bill: "That was what I wanted to discuss: What are the next steps? Obviously we need to resolve this URI question. Do we need a spec that, before the annotations has the official spec. I'd prefer to align just with what they are doing. It would be nice to get a consensus that this is the direction we want to pursue."

<Karen_> Nick: Does the URI standard have a character limit?

<Karen_> Some browsers limit to 256

<Karen_> Ivan: I don't recall

<Bert> (No limit on URLs, AFAIK)

<Karen_> Liam: A lot of current webapps would fail under that

<Karen_> …used to be 72 limit

<Karen_> Nick: I can tell you that Chrome will stop at 512 characters

<Karen_> …I have tried to use URL parameters for email

<Karen_> …it ignores past 512

<Karen_> …Firefox is similar

<Karen_> Liam: Specific to mail or in general?

<Karen_> Nick: I don't know; purely a bug and curiosity about breaking things

<Karen_> …might make selector difficult

<Karen_> …maybe shove into a URI

<Karen_> Liam: A URI within a URI would have a limit

<HeatherF> FWIW, "Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs."

<HeatherF> support.microsoft.com/en-us/kb/208427

<Bert> (DNS names are limited to 256, I think, but URLS are not.)

OK thank you all

<HeatherF> That was just a quick web search

<pkra> +1

Markus: "With 1 minute - are there any contenders for items next week."

<HeatherF> thanks, all