W3C

- DRAFT -

SV_MEETING_TITLE

27 Nov 2017

Attendees

Present
AndyHeath, janina, Lisa_, Becka11y, clapierre
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Sharon

Contents


<Lisa_> scribe: Sharon

<Becka11y> can someone provide me with the link for the meeting? I can’t find it

<Lisa_> https://www.w3.org/2017/08/telecon-info_personalization

<Lisa_> (for becky)

<Lisa_> next issue

Time lines readjustments - do we need extra calls this week?

Lisa: June to have implementations working, but they want it end of March for WCAG required content. A mature working draft for the WCAG required sections.

Michael: We need implementation for March.

Lisa: For the implementation to be useful we need a mature draft.
... Mature implementation for April would be to late.

Mike: WCAG needs to go CR by May, so the implementations have to exist in time.

<Lisa_> https://a11y-resources.com/developer/coga-personalisation#coga-action

<Lisa_> mature specification in febuary

Lisa: Implementations need to be mature by February.

Micahel: Implementations need to be settle in advance, which would be Feb.

Lisa: We should try to finish WCAG AA by December. Not a mature draft, but try not to change prefixes,etc.

Michael: Makes sense but not sure we need a prefix. It could be something else.

Micahel: Only needs a prefix if its an ARIA module.

<Lisa_> close thing that effect impletion for action, destation and field by end decmeber

Lisa: If we want to maximize usefulness for COGA, close things that effect implementation by end of Dec.

<Lisa_> mature draft end feb

<AndyHeath> +1

<clapierre> +1 might slip to Jan, but yes

<Becka11y> +1

+1

<Roy_> +1

Charles: For implementation, you said a Website would not be enough. What do we have to get for the 2 we need and when do we start talking to them?

<Lisa_> https://a11y-resources.com/developer/coga-personalisation#coga-action

<Lisa_> https://github.com/w3c/personalization-semantics/wiki/Implementations-of-Semantics

Micahel: Implementations would be in the form of browser extensions. Would also like to know who the implementers are. Demonstrate something happens for users. Browser extensions is the shortest path.

Lisa: discussed links and asked if they were implementations.

Charles: A11y resources looks interesting. We need to link to that from the wiki.
... Others are just websites that could have an implementation to try out.

Michael: Other sites can't use the implementation for their conformance claims.

Lisa: Helping WCAG requirements so having user agents are important, as well as browser extensions.

Andy: Would style sheets count as an implementations or Grease Monkey.

Lisa: We have a problem with user style sheet supports. Button on a site for example.

Andy: Grease Monkey

<Lisa_> stylish

Andy: Stylish for most browsers that let you have global style sheets and sites.

The survey

<Lisa_> https://www.w3.org/2002/09/wbs/101569/moduleSyntaxScope/

<Lisa_> https://www.w3.org/2002/09/wbs/101569/moduleSyntaxScope/results

<Lisa_> https://lists.w3.org/Archives/Public/public-personalization-tf/2017Nov/0026.html

Lisa: New survey - module proposal. Only 2 results, both yes.

<Lisa_> https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/explainer.html#intro_context

Lisa: Proposal is to make different modules. One for context, another adding help and support, and logs and reminders. Split into tools
... Give context which makes the page adaptable. Help and Support, literal interpretation. Third is enabling logs and messages which is quite advanced.
... Advantage is that we can publish one and a time.
... Use cases pulled into the module, so they are separate to the module but we need a section on use cases for each one.
... We can have an intro for the use cases in the module section.

<clapierre> I think having the use-cases here would be helpful

<Lisa_> +1

<clapierre> +1

<Becka11y> +1

+1

Lisa: Does this need to be a CFC. Michael said he did not think so. Not ready to merge the changes so people can continue to think about it.

Michael: Lisa should coordinate with Roy to make changes.
... The branch was done to demo a proposal for modules. Do not do prefix in the branch. Branch needs to wrap up.

Becky: Is there a branch to work on and Lisa said not right now.

Lisa: will send Roy the table of content and CC the list.

Roy: Will change the branch. He will work on it in his daytime.

Lisa: Will try to get it to list tonight so Roy will have it when needed.

Michael: Would like to review before merge.
... Prefer to do reviews etc., by email.

Roy: List will give him the list and he will change the branch based on the list. When finished he will confirm in email to confirm merge.

<Lisa_> https://www.w3.org/2002/09/wbs/101569/moduleSyntaxScope/results

Lisa: Works for her and Michael agreed.

<Lisa_> given-name

<Lisa_> givenName

<Lisa_> camelcase

Lisa: Syntax results - dashes and others are camel case. Based on survey, 2 results stated schema.org

Michael: adopt a protocol for ourselves, say in the appendix. Example the mapping.
... leans toward lowercase with hyphens.

Lisa: Explain the mapping.

<Becka11y> +1 for consistence

<clapierre> Must be consistent

+1

<AndyHeath> +1 for consistence

<Lisa_> presnt+

Charles: Standard way of vocabulary is camel case, so he pushes strongly for camel case.

Michael: maps to... so we changed it and do it on a global basis.

Lisa: All lower case? Michael stated that without a hyphen its harder to break apart the words.

Charles: for parsing, but if we don't have to worry about it then camel case makes sense.

Lisa: It might be useful with a hyphen.

Michael: Still need to work on the prefix issues.
... Is leaning more toward came case as we talk about it.

<AndyHeath> +1 for camelCase

<clapierre> +1

+1

Lisa: The fields do not specify in the definition if it is user or site info.
... limit the scope of the name field to the users name. Advantage is clarity. My email, my user name, etc. Problem could be shipping or multiple addresses.
... Do we want to scope each field or leave them ambiguous?

Charles: associate any type of the address with the icon. Want to be generic

Lisa: Name field with an icon would be a limited scope.
... Jason is a big proponent of clarity. Does anyone want limited scope?

Charles: Is this auto fill based on semantics?
... How would the developer know to put it in correctly. Reducing the scope adds more burden for developer.

<AndyHeath> 0

0

<clapierre> 0

<Lisa_> do u want limited scope

<Lisa_> 0

<Lisa_> janina is also a 0

Janina: Is a 0

Lisa: Address last item for our call next week.
... CFC passed our prefix is moving to AUI. Adaptable UI.

<Lisa_> https://lists.w3.org/Archives/Public/public-personalization-tf/2017Nov/0037.html

<clapierre> +1 to AUI

<clapierre> 11:03

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/27 19:03:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Present: AndyHeath janina Lisa_ Becka11y clapierre
Found Scribe: Sharon
Inferring ScribeNick: Sharon

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


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


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: 

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.)


[End of scribe.perl diagnostic output]