W3C

- DRAFT -

SV_MEETING_TITLE

01 Oct 2018

Attendees

Present
JF, LisaSeemanKestenbaum, clapierre, MichaelC, janina, Becka11y
Regrets
Chair
SV_MEETING_CHAIR
Scribe
clapierre

Contents


<LisaSeemanKestenbaum> scribe: clapierre

<scribe> scribe: clapierre

jons email https://lists.w3.org/Archives/Public/public-personalization-tf/2018Sep/0028.html

Lisa: we are meant to be publishing 3 drafts this month.

Janina: I think it is reasonable to allow the timeline to slip, because we need to talk to web platforms.

Lisa: I propose to review John's emails. to see if we want to explore.

do we want to request the timeline slips.

5 min review, on the issues.

do we have a good idea that this becomes an issue.

if we do a straw poll with a majority on this call that we need to explore better then we can we slip.

do we have a proposal that is worth it.

Janina: that is a reasonable question, whatever we decide on we need to run by web platforms.

Lisa: we may also need to go to TAG

Jania: we should consider what seems viable / implementable

reminds me in APA that has a work statement, is hand authoring an important requirement we need to have

the whole statement we need to get feedback from this group on that.

John: I don't think spending the time to authoring implementation is very important.

I want to make sure that any solution we have can be scaleable

Lisa: do we have a different proposal that we

John: narrow down to 3/4 proposals and needs a wider review.

Lisa: revew the email you sent and think we can discuss, we had 3, and we were down to 2 but now we are at 3, but there are another 4, we should all look at it.

John can you give a quick walk through,

John: I can do that. 5min ok

I was talking to other people a couple new patterns emerged

discussions going back where discussion cascading attribute sheet, we could have different attributes using class notation, and associate requirements to that class. on upside common pattern, jquery does this

again it would use same notation as css term:value; Lisa I appreciate you may find this difficult, and if one has this issue others may too.

another proposal is to use javascript objects similar to CSS style / json format

the 3rd and final is to create datasets engineers use this in angular/bootstrap, these can be acted upon or not as its just data. there is a link to the pros/cons for each option. and the engineers they kinda like the idea of datasets. they are actually in favor of additional attributes, but pro side we should look at closely and I come back to we need a wider review.

Lisa: any comments go on the queue. I want to separate out wider review vs. looking at these new options.

<Zakim> MichaelC, you wanted to say the data-aui- approach seems like a simple amendment to an existing proposal, but the stylesheets approach is a massive new approach I wouldn´t want to

Micheal: I am not concerned about the data- approach.

I am more concerned about the other two class versions

John: using a class attribute jquery and jqueryui are use to that already,

Micheal: that is one user group and we have others.

John: reusable componets would be nice to have. will there be components that this could be created once and used multiple.

Micheal: we could do the same with ID's

Lisa: each menu item could have different symbols / values, same menu each item having a different easylang, and making people do separate classes, and this doesn't work at all in our senario. I understand for calloutboxes this doesn't work.

adding value to entry, this is going away from W3C approach, AT users we may not be use to people using JQuery or current popular libraries, I want to make something that will last 20 years, but not close to tied to current web java programming.

we are moving away from xpath, xpointer it is breaking the web paradime, we are going to loose a lot. what are the trends today, so I am not for them.

author errors small devs with LD, or material for schools for students, we may not have support to have automatich checkers. and no way to debug.

Becky: I don't see the difference between data- aui- (angular / react) are going back to a database, so I am trying to understand why we think this is a good idea.

John: the engineers he talked to data-aui-* is very similar to aui-*

as more engineers come to they are saying just use a dataset approach.

I don't see a huge difference except it is creating datasets, but these frameworks like react/angular are dealing with data right now, can seemlessly integrate.

I appreciate the initial takup will be smallshops, no one uses dream weaver anymore, the majority of web contact are from databases that are assembled on the fly, I want to address that

if we don't start thinking about how this can scale

emotional markup language is one which didn't scale.

I am not sure I am spending my time in the right place if what we create here won't scale

it is taking ARIA 5-8 years to finally get larger companies to take up.

Lisa: our first developers small groups that have learning disabilities we have 2 implementations are from small groups who have disabilities, and they are not using these

<Zakim> JF, you wanted to discuss author group(s)

Lisa: question: do these 3 new proposals form John are worth looking into in detail. There is a proposal here that we should look at in detail.

<JF> with pros and cons here: https://gist.github.com/schne324/9eda7dbc99954e2d4e44a86515a87f97

<LisaSeemanKestenbaum> back here

<JF> Q

<LisaSeemanKestenbaum> 0

<Becka11y> 1

1+ for data-aui-*

<janina> +1

<JF> +1

<MichaelC> 0 - don´t want to delay timelines, and also don´t want to overlook potential suggestions

<MichaelC> especially when new suggestions keep popping up when we´re on the cusp of decision, I´m concerned about repeated timeline delays

Becky: I like the data* but I like the other 2 as well. would we also have to provide the javascript to implement

Lisa: You think one is worth proceeding,

Becky: I am not sure react, I like the JS object because most people know how to do it, now it is error prone but there is editors to help with that same for css classes

Janian: I just want to see which path is likely to get into mainstream tools.

community participation but the other is how do we get what we propose into mainstream tools instead of just a small niche that doesn't get mainstream adopted and what I want to hear from web platforms.

<JF> +1 to Janina

Lisa: so it sounds like we have to go to next conversation. Hoping to say lets make a stable draft, and if there is a strong case then we can come back. but we should look at making a new time line. We have had this page up for months, we need to move on with what we got.

<Zakim> MichaelC, you wanted to say publish with ¨implementation still open¨

Michael: these are working drafts, they are not complete we have done work on features, I think we do not have consensus I don't think we can pick the most likely one changes. I think we publish what we got, we can same in an editorial note: with feedback requested on implementations.

I do want to say we should stick to timeline,

I want to resist extend the timeline to finalization, I think we can publish a WD with a help we need help on implementation.

John: So Micheal, when I look at 3 modules they are in various stages of readyness, I agree we don't have consensus, I have done due dilligence and publish without implementation

Janina: I don't think we have enough participation to say we have consensus.

Lisa: if we delay we may loose some implementations

We need 2 implementations is in jeopardy if we wait we may loose them due to timelines are slipping, this should not be taken likly, TextHelp is funded now to work on this. Should we take a revote on this topic.

Revote on this topic

should we go with what we have already looked into

<JF> +1 to not having implementation in a stable draft today

<JF> we need to have a wider review

John: TPAC is coming up, we will have everyone, lets wait 60 days, we can get wider review, then we can make an informed decision to ask for a 60 day its 2 months not 2 years.

I think we can get get feedback from TPAC and then we have 1 more month to Dec 1 to decide.

Micheal: we publish a draft now, with vocab changes we have done. we maintain cadence.

<JF> I can live with Michael's proposal

I want to draw more people's attention to it with a BIG editorial that we want implementation.

Janina: STRONG +1

+1

<JF> +1 to Michael

<JF> 's proposal

Lisa: we are giving outselves 60 days to decide on implementation

<janina> +1

<Becka11y> +1

<JF> I am happy to time-box thie eimplementation discussion to 60 days

<JF> sthie eimplementation/the implementation

Vote: on publishing what we have now with 0 implementation asking for help

<janina> +1

+1

<MichaelC> +1

<JF> +1

<LisaSeemanKestenbaum> 0

<Becka11y> +1

Vote: ongiving ourselves 60 days so Dec 1st to decide on implentation.

<JF> +1

<LisaSeemanKestenbaum> +1

+1

<janina> +1

<Becka11y> +1

<MichaelC> 0 - I agree with a goal of giving ourselves no more than 60 days further to finish sorting implementations, but unsure at the moment how solid we can make that time commitment

John: the implementors on board, have we shopped the different options to them with all our options, do any model looks better. that would be great data

Micheal: by publishing this now we can reach out and ask for their feedback.

Janiana: we need to be consistent on how we ask this question to.

Lisa: Micheal you have some outstanding items?

Micheal: Yes but I don't want to hold up the draft proposal.

Lisa: if we are asking for help we need those action items done.

Micheal: requirements documents, and a better introduction in the explainer.

A cleaned up intro might be doable. the introduction to the other modules will say look to explainer, that is most important and editorial note and struggling on implementation.

Lisa: that is really worth doing a delaying a week, and if you can put those 2 sentences in the other intros pointing to the explainer.
... can you add what you just proposed to the wiki please

John: yes I will thanks

<LisaSeemanKestenbaum> to the wiki

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/10/01 18:06:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/matrix/wiki/
Present: JF LisaSeemanKestenbaum clapierre MichaelC janina Becka11y
Found Scribe: clapierre
Inferring ScribeNick: clapierre
Found Scribe: clapierre
Inferring ScribeNick: clapierre

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]