<LisaSeemanKestenbaum> scribe: present+

<LisaSeemanKestenbaum> implementation https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content

<LisaSeemanKestenbaum> will try and send any conslusion to list and if we need to repone it pwople need to say over the next week

<LisaSeemanKestenbaum> https://lists.w3.org/Archives/Public/public-personalization-tf/2018Sep/0006.html

<LisaSeemanKestenbaum> scribe: roy_

<LisaSeemanKestenbaum> scribe: Roy_

<LisaSeemanKestenbaum> scribe: Roy

<LisaSeemanKestenbaum> https://lists.w3.org/Archives/Public/public-personalization-tf/2018Sep/0006.html

lisa: give a overall summary, aui, attribute and attribute pair are available.

JF: worried about the adoption.

<Becka11y> scribe: becka11y

Lisa: we have agreed that RDFa and microdata have too many complications for consideration right now
... ruling out ARIA because we don’t expect support from ARIA WG
... aui is a simple model, like ARIA but a different prefix - people are used to it
... single attribute - we will need to make each of the attribute names longer, link-contact-us vs region-contact-us. Need to make the names more specific; Also, issues when and item has more than replacement
... also more overhead on the page, more parsing issues; can slow down processing
... do we want to keep single attribute on the list of possibilities - it has issues: 1) can only have single value unless concatenate via spaces

<LisaSeemanKestenbaum> do we rule out singl atribute?

JF: believe we can use single attribute for some things; don’t want to be too rigid and eliminate the easier possibilities; I don’t see this as an either or

Michael: I do see this as an either/or discussion. Sees the problem being that single attribute is only one attribute per element; If we need to support multiple attributes than may need to go to pairs

<LisaSeemanKestenbaum> clarificationType = "easylang", clarificationValue= "xyz "

Lisa: clarificationType = "easylang", clarificationValue= "xyz " - is an example of attribute pairs
... two attributes - one is what you are talking about, the other is the value for that type

<JF> What happens if one of those 2 attributes is missing?

Lisa: example: type is action and value is undo. But could allow just clarificationValue=undo

JF: so need two attributes - how are error handled? for example, when value is not appropriate for the type.

Lisa: testing tool could pick up these errors

Michael: we would have a mapping table for the attributes so the error potential shouldn’t affect our decision
... we shouldn’t allow multiple values - that is very error prone

<LisaSeemanKestenbaum> clarificationType = "easylang action", clarificationValue= "xy z undo"

Lisa: can NOT do this: clarificationType = "easylang action", clarificationValue= "xy z undo"

<LisaSeemanKestenbaum> clarificationType = "easylang action", clarificationValue=( "xy z" " undo")

Lisa: can NOT do this format either: clarificationType = "easylang action", clarificationValue=( "xy z" " undo")

JF: We do something similar in CSS, background: could be color or URL, etc. Maybe we want to look at that. There are no supporting tools yet so we can explore more options

Michael: but we can’t do multiple properties /types and multiple values

Charles: case of two attritutes on a single element - you could nest elements. A span inside of a div is a possibility

Lisa: that adds bloat and is harder for author

Charles: how often will we need multiple attributes on a single type?

JF: CSS allows comma separated values on the border? Have we explored that option?

Michael: that only solves the problem if we do NOT have multiple types

Charles: example: have easylang and an alternate phrase in a simple format that might also have symbols

Lisa: might want to say something is important and it is also the undo button; might want both pieces of info in order to determine the simplifications possible

<JF> <button aui="purpose:submit; symbol:url(http://url)">

JF: am proposing that we look at the same type of notification that CSS uses; it allows for a string of properties that are associated with an attribute
... example: <button aui="purpose:submit; symbol:url(http://url)">
... use the same type of notification that CSS uses

Michael: not sure if this is solving a problem that we have

Lisa: problem with single: you can’t have more than one thing (which JF is pushing back upon)

JF: have given a basic example where that exists today - style=<style attributes strung together>

Michael: We hadn’t been considering this as a solution type; thinks it is different from the single attribute proposal we have now. Is a new proposal

Lisa: it does address the problem of addressing more than one type/value pair and it does so in a single attribute

Janina: we should make room to review and document this

JF: authoring pattern is familiar but admittedly there are many type/value pairs to learn

<LisaSeemanKestenbaum> clarificationType = "easylang", clarificationValue= "xyz "

Lisa: need to add this to the table - which gives up 4 options: 1) single attribute; 2) value pairs; (can we throw this out as an option)?
... value pairs - can only have one type per element: clarificationType = "easylang", clarificationValue= "xyz “;
... can we get rid of value pairs as an option?

Charles: it does allow more value options and is easy for people to understand; But we really need to know how much we will actually need more than one attribute.

<LisaSeemanKestenbaum> https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

Lisa: feels this may happen often.
... view the HTML for this page: https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html
... it was built assuming ARIA but you can see that about half of the items have multiple types

<LisaSeemanKestenbaum> rule out value pairs?

<LisaSeemanKestenbaum> +1

<clapierre> +1

Charles: that leads me to believe we should rule out value pairs

<JF> 0

<JF> FYI: https://www.xanthir.com/blog/b4K_0

Michael: agrees that is the primary concern for that model; not sure that is a deal breaker

Charles: clarify - with single attribute can we concatenate things together

Michael: we need to come up with a mechanism to do that. There are options but they do make it more complicated and harder to parser

JF: shared blog post above that drove the suggestion to mimic the CSS notation

<LisaSeemanKestenbaum> button purpose="action-undo">Revert</button>

single attribute with value can only support simple model; can’t support easylang

Lisa: possibly combine single attribute and pairs??
... will update her table to remove RDFa, micro data, ARIA,

<JF> +1 to Janina

Lisa: would also like to remove native but not everyon is comfortable with that

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: Becka11y LisaSeemanKestenbaum clapierre MichaelC Roy janina
Found Scribe: present+
Found Scribe: roy_
Found Scribe: Roy_
Found Scribe: Roy
Inferring ScribeNick: Roy
Found Scribe: becka11y
Inferring ScribeNick: Becka11y
Scribes: present+, roy_, Roy, becka11y
ScribeNicks: Roy, Becka11y

WARNING: No "Topic:" lines found.


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: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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