<scribe> scribe: janina

Review of implementation use cases

<LisaSeemanKestenbaum> https://github.com/w3c/personalization-semantics/wiki/Use-cases

cl: Starts summarization -- looked at several approaches

lk: Thinking of various implementations under consideration -- 3 options

<thaddeus> +present

lk: Believe value pairs may now be off the consideration table
... We've been advised to avoid any complicated syntatical approaches

cl: It was noted that getting a new attrib in html is hard, and getting several is seriously hard

bg: Not sure where we are?
... Seems we're getting conflicting advice
... I'm still confused, so expect an author would be

lk: What would help?

bg: I get how to put in attributes, I don't always understand how they go together when combined on a page
... I get easy lang, but adding the other pieces confuses

cl: Me too
... symbols, numbers free, etc., etc., how do we solve that?
... Are we caught up in if else logic?
... We may need to restrict ourselves to simple use cases at first

<CharlesL1> • one can do a single attribute for may tokens if they are able to be separated with whitespace. In real life they have been shown to be confusing (by implementors- who do not always read and understand every word in the specification) as the context is not clear

<CharlesL1> • a single attribute for may text values: would require a very complex data model if it is even possible - all the disadvantages of value pairs come into play

<CharlesL1> • a single attribute for may URI value: would require a very complex data model if it is even possible- all the disadvantages of value pairs come into play

<LisaSeemanKestenbaum> one can do a single attribute for may tokens if they are able to be separated with whitespace. In real life they have been shown to be confusing (by implementors- who do not always read and understand every word in the specification) as the context is not clear

<LisaSeemanKestenbaum> a single attribute for may text values: would require a very complex data model if it is even possible - all the disadvantages of value pairs come into play

<LisaSeemanKestenbaum> a single attribute for may URI value: would require a very complex data model if it is even possible- all the disadvantages of value pairs come into play

lk: tried single attrib for tokens, then used a split with coga prefix, ...
... We had two developers making the same mistake
... That was our experience with single attrib

bg: Made an error in coding in an area of the page with contact us info

lk: Were trying to handle an area of a page with some contact info differently from the content retrieved from a contact us link in the menu bar
... Since we've had 5 additional implementers who've not repeated that mistake
... Possibly, we can make the attrib name longer to get to a more acceptable html approach
... Not my favorite, but maybe ...
... Is it worth it?

cl: I'd be OK with that
... If it makes it clear and easily understood, that's good
... Helps the code author avoid mistakes

js: Asks bg's opinion?

bg: Still need to see things exemplified, with the in context
... Notes we can't get aria correctly used

<JF> +1 to Becky

<JF> +1 to Janina

<CharlesL1> +1 as well

+1

lk: For the single attrib approach ...

Path forward

<LisaSeemanKestenbaum> just tokens

lk: Is there agreement to try and rewrite and prototype this way?

lw: wide review?

js: Would want to see another draft and prototype before a wide review publication

cl: What do we change? Module 1?

lk: yes

bg: result of ???
... I'm looking at vocab list
... Trying to understand what's a token? and what's not

<Becka11y> https://raw.githack.com/w3c/personalization-semantics/value-list/vocabulary-list/index.html

lk: Suggest we see what we can do just with module 1
... action, destination, and field being merged
... into something like ... function, context, etc
... then through the vocab and make each term longer, e.g. x-y

cl: action-at, action-by, action-cancelled etc ...

lk: yes

qack jf

jf: they're not actually tokens
... At TPAC we were cautioned to avoid micro syntax
... Only similar pattern was track element, which is child of video

<LisaSeemanKestenbaum> ActionHome

<LisaSeemanKestenbaum> LinkHome

<LisaSeemanKestenbaum> purpose=linkHome

<JF> purpose="action" kind="home"

lk: Suggests the 3 attrib approach can be simplified to a compounded attrib name

<LisaSeemanKestenbaum> purpose=destinationHome

<Zakim> MichaelC, you wanted to support merging if the *vocabulary* merits it, but not for implementation reasons (in the case of action/destination/field there could be good reason) and

mc: This could make sense -- I had a hard time with this in the Web for All paper

<LisaSeemanKestenbaum> +1

mc: We need to be careful that what we're doing makes sense

<LisaSeemanKestenbaum> to only if it isnt overloaded

mc: We should not name based on future implementation plans
... Don't overload the name, e.g. destination-home is redundant, it's just home
... We should remember eventually authors will not be writing actual code, just content and the code will come from tooling

cl: Agreement seems to be to see where we can merge these--which ones it makes sense to merge
... We'll accept longer names for now

<LisaSeemanKestenbaum> agreementv merge were there is no conflict and no overloading

thad: We did not have problems when we tried ...
... We need to be able to simply follow the documentation

cl: suggesting we might start on 3.1 and see what we could merge ...

lk: think action field combine most easily
... first thing is to add to the description

cl: control + action name
... and update the description
... OK, Roy will prototype a rewrite, and Thaddeus will create a test implementation
... No meeting next week, 18 February. It's a U.S. holliday

<CharlesL1> trackbot, end meeting

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)

Default Present: CharlesL, janina, stevelee, Becka11y, Roy, LisaSeemanKestenbaum, sharon, present, thaddeus, JF, MichaelC
Present: CharlesL janina stevelee Becka11y Roy LisaSeemanKestenbaum sharon present thaddeus JF MichaelC CharlesL1
Found Scribe: janina
Inferring ScribeNick: janina
Found Date: 11 Feb 2019
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.)