<scribe> scribe: janina
<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 ...
<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.)[End of scribe.perl diagnostic output]