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

Re: Meeting minutes

From: Ivan Herman <ivan@w3.org>
Date: Tue, 14 Apr 2015 06:18:58 +0200
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <299DBE55-5CB5-42E3-9132-4CB5EB98865E@w3.org>
To: Thierry Michel <tmichel@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

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