RE: Updated summary of ways to apply personalization to content

+1

Best,
Thaddeus

From: Michael Cooper <cooper@w3.org>
Sent: Friday, September 14, 2018 5:38 AM
To: Personalization TF <public-personalization-tf@w3.org>
Subject: Updated summary of ways to apply personalization to content


At Lisa's ping, I just went through to update the summary of different approaches to apply personalization semantics to content:

https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content#user-content-overall-summary<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpersonalization-semantics%2Fwiki%2FComparison-of-ways-to-use-vocabulary-in-content%23user-content-overall-summary&data=02%7C01%7Cjjc6476%40psu.edu%7C0d5b7989b9e14179e7b808d61a3eeba9%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636725254873504023&sdata=C%2BAzB6n898TxhAQWKMtSztnDN9i8BJdsBYYQLEH2Hqw%3D&reserved=0>

The only new idea that had come up since the last update was the two-attribute solution; the other suggestions are noted as "not gonna pursue now" so I didn't add them to the summary.

I would say the attribute pair approach tests better than the single attribute approach - *except* there's the big con of not being able to put multiple properties on the same element. With the single attribute that would be possible, at the cost of a very (likely prohibitively) complex attribute content model.

The native feature tests the best of course, with the con we gotta build support for it.

The aui- attributes seem next best, with the main cons being content using it might not validate, and it could be a temporary solution leading to a disruption later if a different long-term solution is taken down the road. I think that's ok if we are clear about that and advise implementers to implement property recognition in a way that can be easily updated, and limit how much deployment on production content we advise until things really shake out.

Based on this, I recommend (personal thoughts only, not binding):

  *   We explore whether the issue of not being able to have multiple properties on a single element is a deal-killer; if no we approach Web Platform about creating those two attributes.
  *   If we don't wind up pursuing the two-attribute model, we explore whether the issue of having a really complex attribute model for the single attribute is a deal-killer (I think it is); if no, we approach Web Platform about creating that attribute.
  *   Otherwise, we continue to use aui- attributes, for now with a big disclaimer in the Explainer saying "this might still change", but explore with Web Platform if it's ok to create attributes with that prefix.
  *   Meanwhile, we also explore with Web Platform if there are any features they think belong in native HTML, and if so a) pursue that and b) decide if those still need to be supported in another way for compatibility with other stuff such as with aui- attributes. If Web Platform says "we want it all" that's great and all the above can go away, but I think that's highly unlikely.
Michael