Independent User Interface Task Force Teleconference -- 29 May 2013

<trackbot> Date: 29 May 2013

<janina> Meeting: IndieUI Task Force Teleconference

<scribe> scribe: jcraig

take up item 11

<MichaelC> drop item 5

<MichaelC> drop item 6

<MichaelC> drop item 7

<MichaelC> drop item 8

<MichaelC> drop item 9

<MichaelC> drop item 10

JS: TPAC, who's going? TPAC webpage needs updating still (no hotel, etc).
... TPAC is November 11-15 in Shenzhen China

Editor's Update

JC: Updates from last call directional events and linear events should use same names as CSS and SVG

they do now

UIRequestEventUI

<jasonjgw> Comments from Rich that directional and linear events should use the same syntax as CSS and SVG were incorporated into revisions.

UIRequestEventInit

<jasonjgw> Questions have been raised about UI request event initializers and the need for an initialization dictionary.

https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#UIRequestEvent

<jasonjgw> See section 3.1.2 of the Events draft.

<jasonjgw> James proposes to contact potential implementors about this issue.

User Module FPWD Strategy Discussion http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0025.html

<jasonjgw> James clarifies in response to a suggestion from Michael that it isn't clear that WebIDL has been limiting so far, but Respec has been (issues raised on specprod list).

JW: been thinking about this for a while now
... questions regarding User Context draft, privacy implications
... Trying to get to the bottom of what issues/actions need to be addressed prior to FPWD of User Context spec
... May need to publish with notes as to which issues are controversial or incomplete; also which are prereqs to publishing

MC: Don't believe we have all the requirements yet
... I'm attempting to eliminate the dupe reqs
... Would we want to sort reqs prior to publishing FPWD or not?
... Could do either; pros/cons to each. Sorting first would delay draft, but also enlighten the first draft.
... No FPWD is complete, but would be good to publish as a complete outline of planned final document.

<Zakim> MichaelC, you wanted to say we still haven´t sorted requirements; do we want to before FPWD (ok either way but let´s examine question) and to talk about general outline

JW: could simultaneously publish requirements and FPWD. Would have the benefit of drawing attention to incompleteness of requirements.

<Zakim> MichaelC, you wanted to talk about where requirements live

JW: other option would be to write full reqs document prior to FPWD

MC: reqs are currently are in a wiki. There was no plan to publish reqs to the TR status pages.
... our charter allows us to co-publish additional "supporting" documents.

JW: Some other WGs publish reqs docs
... just pointing out options we have.
... Want to use requirements to inform the spec, and vice versa.

MC: I do believe documenting requirements will help us proceed towards spec publishing; some delay due to differing views of what those requirements are.

JS: WAI coord group expressed surprise that we have not solicited requirements from outside the WG.

MC: Could appeal to public to look at the wiki; other option to publish FPWD and wait for feedback.

JW: I'd like to see requirements settled before FPWD
... Or at least defined enough to have the spec refer back to the wiki.
... I don't think all controversies have to be worked out prior to publishing

<MichaelC> action-42?

<trackbot> ACTION-42 -- Michael Cooper to consolidate use cases -- due 2013-03-13 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/42

<MichaelC> action-41?

<trackbot> ACTION-41 -- Michael Cooper to create IndieUI Roadmap for both spec: which feature sets should go into 1.0 versions. -- due 2013-03-02 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/41

JW: group action to solidify use cases?

MC: may need to prompt individuals instead of by group

<Zakim> MichaelC, you wanted to say requirements haven´t been difficult to define, as much as scope for which requirements make v.1 and to say incomplete doesn´t have to block FPWD; an

MC: one of the hard issues is to decide not just what should go into each version of the draft; some features won't make it into version 1.0
... legitimate to publish FPWD with privacy section listed as TBD

AH: agree with Michael that we need to solidify and agree on requirements

JS: Wondering recently what the core requirements should be; but with extensibility
... GPII has a very specific need that most clients would not need

AH: working on a crosswalk? of multiple groups needs and requirements: GPII, Schema.org

JW: existing precedent for core reqs and modules as a structure
... also mechanism is not defining the vocabulary
... in order to resolve the scope, it may be to be speced as 1.0, 2.0, or to sub-modularize the spec
... Step 1: collect all requirements in one place, and Step 2: separate the scope after we document the entire list

<jasonjgw> James notes that there is already some provision for extensibility but there are disagreements about what should be included in core. The general core/extension approach seems non-controversial as is the technical mechanism (key/value pairs discussion).

<jasonjgw> He suggests gathering all requirements HHHHe suggests HHHHe concurs with the idea of gathering all potential requirements first and then dividing them into levels of importance or otherwise classifying in order to resolve the scope question.

<Zakim> MichaelC, you wanted to say the question of core / modules or syntax / vocabularies could be something we ask for input on in the FPWD

MC: we could ask the public some questions about core needs versus extensible taxonomies; whether they think these will delay implementations

AH: agree with prior comments; controversial bits are just about what makes it into the core vocabulary

MC: action items? email to list? volunteers?

JW: solicit requirements, consolidate complete list, delete duplicates and overlap, and verify cleanliness of data

JC: I nominate Jason

<MichaelC> JW: willing to send email to list and help with regularizing the requirements that are submitted

<MichaelC> after a reasonable time frame

<MichaelC> and can help back-track to use cases

<MichaelC> JC: some stuff already represented in spec

<MichaelC> and the existing proposals for requirements

<MichaelC> though some refactoring may be needed

<scribe> ACTION: Jason to email group to resoliciting uses cases for User Context requirements; [recorded in http://www.w3.org/2013/05/29-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-54 - Email group to resoliciting uses cases for User Context requirements; [on Jason White - due 2013-06-05].

<MichaelC> e.g., ¨simplified¨ needs more precise definition

AH: why ask the community about requirements yet
... be sure not to disregard proposals in this initial gathering phase; we can determine order later

JC: re: external comments, need to approach this carefully; could result in FUD from non-technical members of the community that could misunderstand some of the reasons for the need for User Context

<Zakim> MichaelC, you wanted to say we can ask for requirements of anybody whom we like, or not do so; but in a FPWD anybody who wants to comment may, and calling out requirements as a

JW: would be fine with having the FPWD point to list of requirements. That should be enough; don't need to make specific requests outside the technical spec reviewers.

MC: can triage the feedback and those comments as we see fit.
... Need to behave in a manner befitting that, but don't need to let the world's comments drag us down and prevent progress.

AH: I can help with the reqs gathering and email that is Jason's initial action item

MC: additional action items will be needed after Jason's is complete

ACTION-54?

<trackbot> ACTION-54 -- Jason White to email group to resoliciting uses cases for User Context requirements; -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/54

- DRAFT -

Independent User Interface Task Force Teleconference

29 May 2013

Attendees

Contents

Editor's Update

User Module FPWD Strategy Discussion http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0025.html

Summary of Action Items

Scribe.perl diagnostic output