- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 14 Apr 2015 06:18:58 +0200
- To: Thierry Michel <tmichel@w3.org>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-Id: <299DBE55-5CB5-42E3-9132-4CB5EB98865E@w3.org>
Yep, I just realized myself. Sorry; done.
I.
> On 14 Apr 2015, at 05:40 , Thierry MICHEL <tmichel@w3.org> wrote:
>
>
> Ivan,
>
> I had also send my regrets
>
> see
> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Apr/0029.html
>
> Please update.
>
> thanks,
>
> thierry.
>
> On 13/04/2015 18:50, Ivan Herman wrote:
>> The minutes are here:
>>
>> http://www.w3.org/2015/04/13-dpub-minutes.html
>>
>> A text version is below.
>>
>> Cheers
>>
>> Ivan
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>> [1]W3C
>>
>> [1] http://www.w3.org/
>>
>> Digital Publishing Interest Group Teleconference
>>
>> 13 Apr 2015
>>
>> See also: [2]IRC log
>>
>> [2] http://www.w3.org/2015/04/13-dpub-irc
>>
>> Attendees
>>
>> Present
>> Charles LaPierre (clapierre), Nick Ruffilo
>> (NickRuffilo), Bill Kasdorf (Bill_Kasdorf), Heather
>> Flanagan (HeatherF), Markus Gylling (Markus), Alan
>> Stearns (astearns), Matt Garrish (mgarrish), Ivan Herman
>> (Ivan), Peter Krautzberger (pkra), Brady Duga (duga),
>> Karen Myers (Karen_Myers), Ben De Meester (bjdmeest),
>> Mike Miller (MikeMiller), David Stroup (david_stroup),
>> Tim Cole (TimCole), Paul Belfanti (pbelfanti), Bert Bos
>> (Bert), Luc Audrain (Luc), Liam Quin (Liam)
>>
>> Regrets
>> ayla, vlad, julie_morris
>>
>> Chair
>> Markus
>>
>> Scribe
>> NickRuffilo
>>
>> Contents
>>
>> * [3]Topics
>> 1. [4]Aria module discussion
>> 2. [5]Packaging examples
>> 3. [6]F2F agenda
>> 4. [7]identifiers
>> * [8]Summary of Action Items
>> __________________________________________________________
>>
>> <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> [9]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."
>>
>> [9] https://rawgit.com/w3c/aria/master/aria/dpub.html
>>
>> <mgylling> minutes are here:
>> [10]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."
>>
>> [10] http://www.w3.org/2015/04/09-aria-minutes.html
>>
>> ...: "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>
>> [11]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."
>>
>> [11] https://www.w3.org/dpub/IG/wiki/OCF_Functionality
>>
>> 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>
>> [12]http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_
>> and_Distribution
>>
>> [12] 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>
>> [13]https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_
>> Details
>>
>> [13] 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>
>> [14]https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Ope
>> n_Annotations_Fragment_Selector
>>
>> [14] 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>
>> [15]http://www.w3.org/TR/2014/WD-annotation-model-20141211/#fra
>> gment-selector
>>
>> [15] 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": "[16]http://example.org/selector1",
>>
>> [16] 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
>>
>> Summary of Action Items
>>
>> [End of minutes]
>> __________________________________________________________
>>
>>
>> Minutes formatted by David Booth's [17]scribe.perl version
>> 1.140 ([18]CVS log)
>> $Date: 2015/04/13 16:50:13 $
>>
>> [17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
>> [18] http://dev.w3.org/cvsweb/2002/scribe/
>>
>>
>
----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Tuesday, 14 April 2015 04:19:10 UTC