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

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