W3C home > Mailing lists > Public > public-digipub-ig@w3.org > April 2015

Re: Meeting minutes

From: Thierry MICHEL <tmichel@w3.org>
Date: Tue, 14 Apr 2015 05:40:31 +0200
Message-ID: <552C8C2F.6010808@w3.org>
To: Ivan Herman <ivan@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>

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/
>
>
Received on Tuesday, 14 April 2015 03:40:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:59 UTC