W3C home > Mailing lists > Public > public-personalization-tf@w3.org > September 2018

Re: mix proposal

From: Charles LaPierre <charlesl@benetech.org>
Date: Tue, 18 Sep 2018 13:51:12 +0000
To: "lisa.seeman@zoho.com" <lisa.seeman@zoho.com>
CC: public-personalization-tf <public-personalization-tf@w3.org>
Message-ID: <5E08232C-5075-4FB3-88CC-0910379E7B1B@benetech.org>
This does look interesting, and I like the idea if you don’t include the type easylang is assumed if that we think will be the most used option to cut down on amount needed to be authored.
Does the syntax work for you all (ie. space separated)?

On Sep 18, 2018, at 2:22 AM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:

I am wondering about the following mix

1. A semi complex single attribute for context   <button aui="submit critical symbol(http://uri.html<http://uri.html/>) step(5)" > These are all content descriptors. This allows more then one context descriptors from fixed vocabularies and symbols. The con is it is slower to parse, slower to process and some more author error as the vocabularies are not separated. I am not sure if it works with things like css selectors.

2. Then we have a clarification  value pair for free text for easy lang, litral etc. this could be like

clarification="this costs less money" clarificationType="easylang numberfree"

If you do not fill in clarificationType the default is easylang.

Note the aui- option is still easier to parse and will probebly have much better performance. this is a big issue for implementations

I suspect we should have tow option and go to web apps and people like James for their opinion.
All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>

Received on Tuesday, 18 September 2018 13:51:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:56 UTC