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

[Minutes] 2015-07-13 Digital Publishing Interest Group Teleconference

From: Thierry MICHEL <tmichel@w3.org>
Date: Wed, 15 Jul 2015 10:38:26 +0200
To: "public-digipub-ig@w3.org >> W3C Digital Publishing IG" <public-digipub-ig@w3.org>
Message-id: <55A61C02.9090703@w3.org>
Hi all,

The minutes of the Digital Publishing Interest Group Teleconference 
dated 2015-07-13 are now available at

     http://www.w3.org/2015/07/13-dpub-minutes.html

These public minutes are also linked from the dpub wiki
     http://www.w3.org/dpub/IG/wiki/Meetings

Also find these minutes in a text version following, for your convenience.

Best,

Thierry Michel


--------------------------
    [1]W3C

       [1] http://www.w3.org/

             Digital Publishing Interest Group Teleconference

13 Jul 2015

    See also: [2]IRC log

       [2] http://www.w3.org/2015/07/13-dpub-irc

Attendees

    Present
           Deborah Kaplan,Tim Cole, Chris Liley, Nick Ruffilo,
           Heather Flanagan , Charles LaPierre, Tzviya Siegman,
           Markus Gylling, Bill Kasdorf , Karen Myers

    Regrets:
           Ivan Herman, Luc Audrain,  Vladimir Levantovsky, Alan
           Stearns, Laura Fowler, Zheng Xu, Ben De Meester.

    Chair
           Markus Gylling.

    Scribe
           Nick Ruffilo

Contents

      * [3]Topics
          1. [4]Fragment Identifiers Status Update
      * [5]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 13 July 2015

    Markus: "Approve last week's minutes - any objections - speak
    up now"

    Tzviya: [6]http://www.w3.org/2015/07/06-dpub-minutes.html

       [6] http://www.w3.org/2015/07/06-dpub-minutes.html

    Markus: "Great - thank you.  In terms of the short agenda -
    there has also been some postings from George Kersher - his
    reply to the ARIA-described-at"

    Tzviya:[7]http://www.w3.org/blog/2015/07/aria-and-dpub-publish-
    fpwd/

       [7] http://www.w3.org/blog/2015/07/aria-and-dpub-publish-fpwd/

    Markus: "Lets run through the agenda as published.  The first
    thing - we have a URL to a blog post which points to a number
    of questions for the community.  Tzviya can you take us
    through?"

    Tzviya: "We published this draft with a little note at the
    beginning saying "don't use this yet" there are a list of open
    questions - some pro forma, some we need to work out.  One of
    the issues that arose are included in the questions.  The first
    question - what are the roles that are needed by the digital
    publishing community - such as glossary, index...  Some are
    less clear such as 'epub-part',
     notice... and we want to make sure people understand them."
     ...: The 2nd question is the use of the dpub- prefix is OK
    without conflict?  But there was a great deal of debate and the
    conclusion that a formal extension needed a prefix - but we
    weren't sure if it should get a - or a : so it's dpub- prefix.
    does this work with your workflows, will you use it - we want
    to make sure it will go into practice."
    clapierre1: q+

     ...: "3rd question is what mechanism will be suitable of new
    roles - we want to make sure the document is extensible
    itself.  "
    clapierre1: +q
     ...: "Last question - is it clear how to sue this with the
    aria 1.1 knowledge.  We discuss this today - you can put
    feedback in email or post them in github in the document."
    mgylling: q?

    Tzviya:: [8]https://github.com/w3c/aria/issues

       [8] https://github.com/w3c/aria/issues

    Markus: "charles - you had a ?"

    Charles: "The ARIA role: I'm just worried we are going to get
    pushback from the forces-that-be concerning 'why is this needed
    in the ARIA domain for accessibility specifically' when it
    should be beneficial for anyone to know something is a footer,
    glossary, header, footer. I'm concerned they will reject the
    roles because it's not accessibility specific"

    Markus: "Is the concern the accessibility camp rejecting? or
    the general people?"

    Charles: "The ARIA world - that it is so broad that will not
    want it."

    Markus: "We had quite a bit of discussion around that and the
    question boils down to - how generic is the role? And there are
    others which represent what you fear - that it should stay very
    focused on very particular isolated tasks. There are some works
    to be done on ARIA-land there for the future of the attribute."

    Tzviya: "This is one of the things that made it take so long-
    that we've been working with the chairs of the ARIA group - and
    they felt very strongly that accessibility isn't just for
    people with disabilities. Accessibility can serve the entire
    community."

    Charles: "I agree with you. There are also times where people
    are situationally disabled - such as the use of close
    captioned. Just making sure we've pointed this out."

    Chris: "I guess some of what I'm about to say has already been
    said. The aria attributes are seen as sign-posts and symantic
    flagging - which points towards accessibility - which is for
    people who need it - but not always for people who need it.
    They are semantics that people can hook off of to get more
    value from the content."

    <tzviya> link to actual spec:
    [9]http://www.w3.org/TR/2015/WD-dpub-aria-1.0-20150707/

       [9] http://www.w3.org/TR/2015/WD-dpub-aria-1.0-20150707/

    Bill: "On theme that I hear constantly is the concept of
    mainstreaming - that it's better that people needing assistive
    technology NOT get special treatment - but that people are all
    using the same files that everyone else is getting. So the fact
    that these are generally useful is a good thing. It's better
    that it is 'not special' and works for all"

    Markus: "I thought I'd add for clarity: In the blog post the
    term prefix is used to describe the dpub- prefix - they are not
    prefixes as we have gotten to know them - that they are not a
    separate thing from the term - they are hardcoded into the
    role. It's good for people who dislike prefixes, but there is
    also a potential drawback in terms of vocabulary if one has the
    ambition to create a

    generic vocabulary, such as in other XML vocabularies, then it
    is a drawback to have this ARIA specific tweak hardcoded into
    the name."
    ...: "This issue is why it took so long to get through the
    working group, etc. And this is the rules that it came up
    with."

    Markus: "Tzviya - you talked about the 3rd role. And this is
    just a subset of what we really need in the long-term. We know
    that peter has things related to STEM. Do you have any thoughts
    at this point in terms of what kinds of mechanisms we are
    looking at? Yet, on the other hand, we don't want things to get
    out of control."

    Tzviya: "Well - part of the mechanism is - who is responsible
    and who has governance. One of the issues with prefixing is
    that authors should have governance - the joint task force of
    DPUB and ARIA. Since it's a beach group - it should be OK. "
    ...: "ARIA has a heartbeat process that slims down the items
    needed to get in additional terms, etc."
    ... "In terms of what the vetting process is - that relates to
    governance. And the way this relates to EPUB also needs to be
    discussed."
    ... "If you have any input on this being a prefix - we want
    your feedback. We want feedback on all of these things.
    Especially if you're working on a reading system or work for a
    publisher - offer a comment. Please!"

    <Karen> Nick: My question

    <clapierre1> /me no more vadar :)

    <Karen> …with the prefix the only concern I might have

    <Karen> …is dpub the correct prefix?

    <Karen> …Reason I ask that is

    <tzviya> nick: my concern with the prefix is whether dpub- is
    the correct prefix

    <Karen> …if I am a web developer and say, 'oh this is for
    digpub and not doing epub, why should I use this prefix?

    <Karen> …is dpub a limiting factor? Is it generic and usable
    for entire web

    <Karen> …or is there a better prefix to show it's just not
    about publishing and books

    <Karen> …maybe I'm overthinking?

    <Karen> …but it's a comment to get out

    Tzviya: "So, we intentionally chose DPUB intead of EPUB -
    because DPUB is the name of the group, but we are open to other
    suggestions. Before this becomes final - some terms might get
    rolled up into the ARIA core spec. Especially things that might
    be useful for everything. If it is part of just regular ARIA.
    We are open to recommendations of prefixes."

    Deborah: "We tend to see things in a box - but I wonder if some
    of the new platforms will think of themselves as digital
    publishing - even if they have the same needs. They will see
    themselves as "content platforms" not publishers - if we
    preface terminology with publishing - that may cause people to
    not look it up for themselves and their clientelle. Possible
    decouple from the industry in a

    way."

    Markus: "Lets try to wrap it up

    <ChrisL> rel does seem the typical way to specify link types in
    general

    <clapierre1> so this item will be removed? dpub-locator

    <clapierre1> A link that allows the user to jump to a related
    location in the content (e.g., from a footnote to its
    reference, from an index entry to where the topic is discussed,
    or from a glossary definition to where the term is used).
    ...: "In terms of next items, lets revisit the vocabulary. 2 -
    discussion of moving some of it up to ARIA core. There are
    pros/cons to that. Having some with and some without prefixes
    can be ugly. The 3rd is links - so one of the things we ahve in
    the epub category is semantics for links. We had a few proposed
    in an earlier editors draft - which were emphatically shot
    down. We also say

    links are defined by REL and not ROLE. Kind of ugly to have a
    vocabulary party in ROLE and some on REL... Doesn't look like a
    good setup for a vocabulary for me. that's the 3rd priority for
    the task force."

    Tzviya: "Other big priority is that there is a companion
    document. and API mapping document - which is a great deal of
    work - so if you want to join in the fun and know how
    accesibility works, please do."

Fragment Identifiers Status Update

    Tzviya: "We were going to re-iterate the idea of service
    workers and Fragment IDs"
    ... "Bill, Ivan's email should be shared with the list - it was
    very clear."

    Bill: "I'm not technically knowledable enough to talk about
    service workers, but I can at least provide ahigh-level.
    Fundamentally the way it has evolved is leading us AWAY from a
    particual spec - because the service worker approach may give
    us what we want in many context and because - also - and I feel
    strongly - that this is another example of this group should
    NOT create a spec but we shoudl

    come up with a spec of all the identifiers that are already in
    use for different media types. "
    ...: "Service workers is what helps us get to the granularity
    we need to use those identifiers. Ivan uses a set of
    progressive examples on how you point to different things. One
    thing that will help further is the range-finder spec which is
    being defined. I believe that is the right direction to go. If
    anyone else from that call is on, and they can comment on the
    likelyhood of that coming

    out of annotations - so that we don't have to define yet
    another spec, that'd be great."
    ...: "The point of getting directly to a point that doesn't
    have existing structure or markup is important. Tzviya - markus
    - please correct/add."

    Tzviya: "Fragment identifiers are definitionally - to date -
    are tied to content type. EPUB-CFI is tied to the strucutre.
    What we're looking at now with identifiers, is that they are
    gathering different types of identifiers is that they are using
    the URI to point to different types of identifiers. The package
    identifier could point to many different types of identifiers.
    In epub-web we're

    looking to point to different types of content types."

    Bill: "I hope we can do that too"

    Tzviya: "The way service workers works means we can think about
    storage and the way we think about pointing at things. Because
    things can be stored online in a simpler way."

    Markus: "Yes, in a canonical location - but it doesn't stop
    them from being offline. "
    ...: "Bill - what does this mean for your task force. I'm
    thinking we still have alot of wishes that aren't satisfied by
    the open web platform today - temporal locations, etc.
    Obviously we are not alone in dpub to want these things. It
    appears we are the first-hand consumer of that more finely
    grained and fancy things. None of these needs should be
    addressed directly. "

    Bill: "In terms of questions - what does this mean for the task
    force? This changes an action item I've had - to come up with a
    definition of what we need for fragment IDs. Something that
    enumerates what the needs are."
    ...: "I am on the working group - nominally. Ivan is on the
    workin group in a larger capacity - so we can work to make it
    better."

    Markus: "We should work in other relevant working groups and
    help promote our use cases. Is there anything else we should be
    focusing on beyond ranges? Are there other opportunities."

    Bill: "I suspect the publication ID is the elephant in the
    room. That's the vision of the epub+web - is that it will have
    an identifier offline and on..."

    Tim: "I guess i'm a little concerned here about the completion
    between identifiers and APIs. In the annotations we tend to
    talk about range-finder as an API - you get the results of an
    API. You give params and it says "I think you're talking about
    this content. There are fuzzy search options - other things
    going on... In terms of an identifier, it's not persistent -
    because if the HTML changes,

    the API may return something new. I think this is true for
    other things as well. One of the things the task force has to
    address is recognizing the difference between a TRUE identifier
    and the ways to get through to a resource that isn't defined
    the way they are today on the web."
    .,.: "I just wanted to suggest - even with Ivan's good thinking
    - there is a bit of additional work left until we really know
    what we're talking about - and how we're using it."

    Bill: "Thanks - Your perspective is very critical on this.
    Specially we want to articulate those issues."

    Tim: "If you talk to someone who has a very strict definition
    of identifier, they will think you're speaking gibberish..."

    Bill: "Are you suggesting that maybe it's ill-advised to speak
    of it in terms of identifier - and call it a navigation guide?"

    Tim: "Possibly: there are these terms when used for percisions
    - and there are these other mechanism that operate a little
    differently. We may want to bring those two concepts under the
    same umbrella and 'navigation' may be a good name for it"

    Bill: "A common problem is that people want a single identifier
    that does everything. In this case - the solution possibly is
    lots of different identifiers - but calling it a navigation or
    something else might help."

    Tzivya: "The range-finder API does product a URI, is that
    correct? I believe the draft is changing, but I believe the
    latest draft does let you pack everything into a URL. It's
    basically a query string - so I don't know if he's using the #
    or a ?. The latest version is up on GitHUB"

    markus: "We spoke to Doug last week and that it would at least
    be in the range-finder spec. Ivan's email still expressed that
    as an unresolved issue."

    <TimCole>
    [10]http://w3c.github.io/web-annotation/api/rangefinder/

      [10] http://w3c.github.io/web-annotation/api/rangefinder/

    Tim: "I think this is the state of what's in there now. we
    talked alot about the API near-phase."

    Bill: "I'm feeling that we have a very promising sense of
    direction towards something that will actually work - which is
    a big step. This is something that having a call of the
    task-force in the next week or two is a good idea. Do we have
    enough now to draft that note to the community?"

    Markus: "Finally - charles and Deborah, thanks to all of you
    for the reply to PF regarding the ARIA-Describedat."

    Charles: "I wanted to give a shout-out to Deborah for doing the
    heavy-lifting on the document. It was a nice collaborative
    effort in getting that done and we thought it gave the most
    sense for George to send it with his weight behind it. I think
    that it was a good document and showed our concerns and
    hopefully will sway the masses."

    markus: "One thing we should make sure we do is that we're
    around on the PF calls when they end up discussing this. George
    and I are on the PF calls but we don't attend all the calls.
    But we need to make sure we show up. Are you a member Charles?
    "

    Charles: "No, but i was invited to one of their meetings. Yes,
    i'll definintely check it out. First week in August I'm on
    vacation."

    Markus: "I'll talk to Jinnie and Rich and see when they will be
    up for discussion. I'll make sure that they know and invite us
    accordingly. Any questions/remarks?"

    Tzviya: "You mentioned joining a PF meeting. Rich had commented
    that it might be valuable for non-members to join a meeting of
    PF to discuss the described-at. Especially anyone who is making
    tools that are making use of described-at. if you are
    interested in joining a meeting and you are using (or plan on
    using) described-at, please let us know. if you knwo someone
    who might be interested,

    let us know."

    Markus: "Is there any other business today?"

    <pkra> bye.

Summary of Action Items

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [11]scribe.perl version
     1.140 ([12]CVS log)
     $Date: 2015/07/14 21:14:25 $
      __________________________________________________________

      [11] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
      [12] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at [13]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [13] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/<dl epub//
No ScribeNick specified.  Guessing ScribeNick: NickRuffilo
Inferring Scribes: NickRuffilo
Present: Liam_Quin

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 13 Jul 2015
Guessing minutes URL: [14]http://www.w3.org/2015/07/13-dpub-minutes.html
People with action items:

      [14] http://www.w3.org/2015/07/13-dpub-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.



    [End of [15]scribe.perl diagnostic output]

      [15] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
Received on Wednesday, 15 July 2015 08:38:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:27 UTC