Protocols and Formats Working Group Teleconference -- 28 Apr 2015

<trackbot> Date: 28 April 2015

<scribe> scribe: janina

rich: Suggest to start looking at what raised issues not yet resolved

<tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html

ts: Spent time preparing for this call, prefix is issue
... Concerned to understand what an ARIA "module" actually is

rs: Situations like role "part" will be a problem

tz: But not resolved before FPWD?

rs: Don't think so, but others may have other view.

<tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html#co-evolution

janina: Noting that early 1.0 implementations burned our spec development -- People are now careful from that experience

rs: We have a different situation here, but it does explain the careful approach

<Zakim> jcraig, you wanted to say FPWD is first opportunity to implement. Reluctance to change implemented values was a major drawback.

jc: Yes, early adoption of properties and role values that weren't best choice, but we were later reluctant to improve because of existing implementations

<ivan> +1 to put a note in the document

jc: Even if it stays for FPWD, issues with known problems should be well labeled to avoid implementations

<mgylling> +1 to put notes in the document for all props with issues

ts: Certainly OK with adding notes, but have a proposal ...

mg: Started with Shane's email comments ...
... Struck by RDFA comments, lack of same flexibility, i.e. global

<ShaneM> Note that the Role Attribute Recommendation ALREADY supports @vocab as a way of changing the default vocabulary for @role

mg: Seems rdfa considered multiiple vocabs

<tzviya> https://lists.w3.org/Archives/Member/w3c-wai-pf/2015AprJun/0031.html

<ShaneM> ARIA doesn't necessarily embrace this presently

mg: The rdfa approach would be very helpful for us
... q becomes is it a good idea to pack things into a single vocab
... concerned with maintanance

rs: Unfortunately, will be pulling semantics for tests, drawings, etc., etc., and all that will end up in books
... And we have no way to switch vocabs on the fly
... What happens to an svg drawing in the middle of a book? Etc.

mg: This an age-old problem now ...
... But declaring a default then using the available mechanism to declare additional should help
... If PF will expand and involve other content domains, can there really be one list?

ts: Just want to note that we believe there are existing roles that we believe will be more generally useful -- without prefix,

sm: Don't believe any AT's support vocab switch, but the spec does support

<clown> http://www.w3.org/WAI/PF/role-attribute/

sm: Vocab is not the solution, vocab is good to use, but the switch won't solve the problem
... Please remember we're trying to expose meaningful semantics for a11y

ivan: Noting how it works in rdfa, vocab attrib on anything, so ...
... think it should be different for aria
... we think there are values that should be global
... suggest working out what's global and what's local to a particular doc
... Don't understand why rdfa switch isn't a solution, even if it's not the best solution

sm: Syntax is well defined, but not for additional name spaces

<Zakim> jcraig, you wanted to say that potentially solves parsing confusion, but not author confusion.

sm: Don't know how to say XX is an ARIA term, not a generic

jc: My main concern is author confusion
... Unlikely a definitve source of values

s/definite/definitive/

jc: Agree we will find globally useful terms

<jcraig> http://www.w3.org/TR/wai-aria-1.1/#text

<jcraig> As with any ARIA 1.1 role, authors may provide a fallback ARIA 1.0 role.

jc: Future of ARIA was set up to have chain of roles

<ShaneM> From an ontology perspective, if we are creating independent vocabularies, it would be MUCH better to use dpub:foo than dpub-foo. Then then semantics are well understood

jc: Best path is to start with prefix, and wait for review and adoption to promote some to generic
... no risk of name trampling this way

<ShaneM> note that @prefix is part of HTML 5 and allows definition of the mappings from a prefix to a URI

<ShaneM> so follow your nose interpretation of terms comes for free

rs: Q: Won't the mark up for epub be auto-generated? by author tools? not by hand?

mg: Tried over the past years, but hasn't succeeded so far

jc: Can you explain the concern?

mg: People do still hand code
... It's a hard sell in the epub world, these are people who probably care more than anyone about semantics--that's historic to publishing
... Concerned that starting with prefix, but after sometime transitioning to a generic role would be a problem as well
... We would be stuck actually

<jcraig> fallback role set up to support="chapter pub-chapter"

<jcraig> role="chapter pub-chapter"

<ShaneM> note that role="chapter pub:chapter" is also supported

<richardschwerdtfeger> :-P

jc: At least in webkit, adding prefixes is trivial, so not as concerned about prefix petrification

<ShaneM> and prefix="pub: http://www.example.org/myvocab#"

jc: notes that role=none for role=presentation was one line of code in webkit

ts: hyphen is valid?

rs: yes

ts: our goal is wide adoption, we had problem with takeup in epub

<jcraig> role="pub-abstract summary"

rs: Noting we're considering a draft ....
... What if we put the prefix in for fpwd, add a note, then go discuss with pubs
... This would actually lock in semantics, no one could take them elsewhere

ts: Noting current participants are pub representatives, that's why we're here

rs: Still trying to understand why it's a problem
... Recall the concern for validation, but we can achieve that

<Zakim> shaneM, you wanted to explain @prefix is part of HTML 5 and allows definition of the mappings from a prefix to a URI

rs: Noting our history arguing with HTML over the delimiter -- half a year over hyphen vs colon

sm: Noting again that machine understanding for semantics is well defined by rdfa

ivan: Skeptical that people will use only authoring tools, it hasn't yet happened, still have to go into code from time to time
... If someone can pull this off for HTML, o0utstanding
... Our problem is that publishers would have difficulty using prefix

<Zakim> ShaneM, you wanted to talk about why using @vocab is not the solution

sm: Today ARIA spec doesn't indicate that vocab controls -- a substantial problem because we already have many implementations

ivan: which is why I don't like vocab, it's not the same as rdfa

<ShaneM> so its @role-vocab?

ivan: believe we're offering roles that will work for many communities

<ShaneM> defines the URI prefix for naked terms used in attribute values

ivan: role vocab would define a dom subtree, where we could use terms without prefix

<Zakim> jcraig, you wanted to mention that the role parsing in UAs is a flat list, so the dpub roles could be used outside the epub context... just in regular web apps and to say

jc: Don't want to digress but understand xh+rdfa complaint was runtime access to on line

ivan: not the case here

<ShaneM> XHTML2 never required that sort of external resource retrieval... but whatever

ivan: I want to keep away from rdfa

ian: we're defining a module that makes the author's life simpler

rs: so if we put vocab at beginning, start role=chapter, then mid point we put an svg drawing
... what happens?

<ShaneM> AND what gets passed to the AT

rs: Note we're also talking attribs, not just roles

<ShaneM> remember that a role name is not just a string of characters. it conveys rich semantic information that influences the current element and its children!

ivan: is it much more complex for the author to make those switches?

<jcraig> q later ShaneM

ivan: we know we don't have a 100% solution, we're deciding among suboptimal solutions

<Zakim> jcraig, you wanted to mention that the role parsing in UAs is a flat list, so the dpub roles could be used outside the epub context... just in regular web apps and to say

jc: noting that javascript is often hand coded
... all roles are parsed as in a flat list, anyone can use any role in any context

<ShaneM> technically role="main" today should be passed to the AT as http://www.w3.org/1999/xhtml/vocab#main

<ShaneM> I know that it is not... but it should have been.

<Zakim> ShaneM, you wanted to ask what happens to references to core roles? and to and to ask what happens to references to core roles? and to and to

<Zakim> later, you wanted to ask what happens to references to core roles? and to and to

sm: implication that nonvocab specific generic terms will still be available ??
... role=baegel main
... need at that knows "this is the main content"
... just don't understand how it mapps out

<ShaneM> +1

<ShaneM> URIs are SUCH a good way of disambiguating terms

janina: suggesting we're pushing user agents to be smarter with domain specific semantics

rs: Clearly we have more discussion, but what gets us to an fpwd?

<jcraig> prefix placeholder is the only suggestions I've heard that will satisfy me for a FPWD

<ShaneM> +1 to adding notes about role values that are of concern

ivan: Make the situation clear, publish as is but note the prefix concern in a global way
... add both solutions discussed, and ask for comments
... clearly note this needs solution before the document can progress

<ShaneM> sorry _ uave to leave

jd: like most of the proposed roles, suggest putting a subset of these as fpwd

ivan: yes because i believe mosttterms are indeed generic, but no because we need to vet the problem terms and approaches

<Zakim> jcraig, you wanted to say if you publish without profixes, you need a clear RFC-2119 "User Agents MUST NOT implement this FPWD"

jc: suggest a clear rfc2119 "MUST NOT" implement
... Could also take the generally agreed ones directly into aria-1.1

<richardschwerdtfeger> we are looking to get into cr later this year

ts: gets fpwd, but what to do with the problem terms isn't vetted

<richardschwerdtfeger> toward year end

rs: also discussion in pf of how modules work

jc: don't understand why publishing is waiting on this?

ts: not everything is epub

rs: the role attrib will validate, which helps pub

<richardschwerdtfeger> aria-value=

<richardschwerdtfeger> “pub”

ivan: likes rs's idea -- we're trying to get proposals

- DRAFT -

Protocols and Formats Working Group Teleconference
28 Apr 2015

Attendees

Contents

Summary of Action Items