short update on module 3

Janina: No one had an update for module 3.

<sgoto> would it be helpful if i described high level?

<sgoto> happy to answer questions, but happy to give a high level overview too

Michael: There are different visions for how we can make personalization happen. So the vision I understand is that we are creating properties to tailor the user experience. How do we want to do that? Metadata, RDFa, etc. Sam was trying to explorer... Are there other ways to do this?
... Additional attributes module? Still end up with attributes that are natively defined. It is a different approach.
... We still would have a strong case where we need use cases, etc.
... Sam was trying to explore a vision... what if we leave it up to the author and ask authors to be creative, using script frameworks, etc. and incorporated later in user agents.
... Personalization could be more of a 3rd party thing. Web annotation would be another example of a different way to implement personalization. Maybe we can separate visions to figure out which ones we want to explore and clarify requirements.

Janina: Sam is there a nuance that may have been misses?

Sam: With regard to goals we are trying to accomplish... proposal was to offer alternatives to get to the vision. It may be unclear or not aligned. Its not clear what the vision is. Is there places I can read about the vision?
... Delegate the exploration of annotations for framework. Taking easylang for example... enable content authors to make numberfree so users can turn a number into language to be consumed. What are the low level primitive we need to add?
... API that tells what is the user preference? Would they prefer numbers or strings? Expose a browser setting that applies to all tabs. That's what I mean by a low-level API. Consistency across origins.
... I haven't seen it written down if consistencies are a requirement. Its unclear is we sprinkle metadata on the DOM content is the way to go.

Janina: We are operating under an expected constraint. What we do may not make it into native code.... Maybe thats not true. Draft APA charter comment from a developer that maybe this should be built-in. Its not just for accessibility.

<Zakim> MichaelC, you wanted to say innovation in the wild optimal and to say user preferences so varied, less useful for authors to hard-code a couple alternatives and to say swappable

Michael: Native user agent support, but it will not emerge quickly. Somethings may get up quickly due to overlap. Likely to be in the domain of plugins.
... The hope would be that there are a lot of approaches. Its important to keep in mind the reason we focus on personalization there is a lot of approaches for personalization, but they may not provide the full richness. Script libraries can be hot swap for another that could be an alternative approach that works.

Sam: 1) That incite that you are expecting short term for this metadata to be consumed by plugins should be called out.
... Seems to me that talking about extensions and plugins is a different design then browsers and search engines. To be clear is I am exploring low level JS API that extensions and plugins could have access to enable framework authors to have the ability to map content on the page. Its not necessarily conflicting. Suggesting that we have to decide what the data model is regardless of notation.
... It does not seem smart to be opinionated about how to make those annotations. It seems like you can decouple these things.

Janina: Providing the tools and primitives to be able to tailor that works for a particular use. I doubt anyone would reject that if it can be done. Libraries are just another version of extensions. We may need to take it up with people who have AT needs.

<sgoto> <script src="http://w3c.org/personalization/microdata.js">

<sgoto> <script src="http://w3c.org/personalization/microformats.js">

<sgoto> <script src="http://w3c.org/personalization/rdfa.js">

<Zakim> janina, you wanted to talk about the case of the telephone

<Zakim> MichaelC, you wanted to ask how JS API might relate to AOM and to talk about practicality of authoring API vs attributes

<sgoto> yep

Michael: Simplest way to start is attribute and JS API would also work. If we explore there should be collaboration. There is still the question of how we make the needed info available to the API.

<janina> https://wicg.github.io/aom/spec/

Michael: It may be hard without hooks for classic content authors.

Sam: Parallel trends not an alternative.
... There is not always a one to one to DOM nodes. To be creative about what I am exploring. I was imagining that there is a library that people can embed as a result of this work.
... Call if personalization object model similar to accessibility object model that exists in libraries and frameworks that maps source code locations in the DOM to the personalization object model. Authors would not write but include the scripts.
... On the other side we have extensions and plugins.

Michael: Would like to think through to think if it is an optimal way to go. This could make it more generic and more rich. Also mapping existing elements and attributes that we can reuse.

Janina: Concerned that we are not looking at a wide enough use cases. Depends on who... we want the browser to pick up OS settings and map that through. For low vision it can be critical.

Sam: APA conversation is to bring up work to ensure content is correctly pronounced by speech engines.

correction.. prior comment is Janina.

Janina: We not done a lot for cognitive disabilities. What is the scope of what we are covering. We need to make sure it covers as many use cases as possible.

Sam: That is what Sam has been asking for concrete use cases. As a group we need to have 4 or 5 concrete use cases.
... Is suggesting a preference, with showing there is a different way to accomplish your goal they are not fully articulated.
... How concretely does an extension or plugin help a user for forms?

<Zakim> sgoto, you wanted to talk about AOM and practicality of authoring APIs

<Zakim> MichaelC, you wanted to volunteer <sigh/> to clarify use cases and requirements (first draft)

<sgoto> :)

Michael: We have had a common background and haven't clarified some of these things. We need to write down the answers to the questions your raising.

<scribe> ACTION: Michael should take an action to explain the use case and get it written down concretely.

<sgoto> +1

Janina: Can we have use cases and requirements in a single document?

Michael: agrees to that preference

Janina: Are you making similar points with internet digital publishing? Did I miss hear.

Sam: No that term is new to me. Close with what Michael just said... all that your saying is new to me. By making yourself able to explain to someone new may make it easier to clarify requirements.

Janina: We need to clearly articulate to propose solutions.

Sam: Would be happy to review any document.

Michael: Do the use case make sense and are there any missing.

Sam: Prioritization... I have a better understanding of easylang and numberfree... start with the forms module.

<sgoto> sgtm

Michael: What we need to do is have a timeframe when we will have a first draft when the use cases will be done.

<sgoto> it does for me

<sgoto> i'm available for the next two weeks

Michael: No less then 2 weeks no more then 4. Is that OK

<sgoto> to work on this with yo

<sgoto> happy to meet offline

Michael: Set a due date of 27 Aug. for first draft.

<sgoto> +1 for progress

Janina: Any other busy?

<sgoto> sgtm

<sgoto> see you all

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: LisaSeemanKestenbaum, MichaelC, sgoto, janina, sharon, Roy
Present: LisaSeemanKestenbaum MichaelC sgoto janina sharon Roy
No ScribeNick specified.  Guessing ScribeNick: sharon
Inferring Scribes: sharon

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: michael

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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)