Report of personalization tech talk

A couple weeks ago, Roy and I presented a summary of the Personalization 
Semantics specifications to the W3C Team. This is something we do 
routinely with projects to bring people working in other areas up to 
date and to get input from people with different perspectives on the 
work. I wanted to share the results of that with the task force, as it 
could be helpful as we continue to develop the specifications. Team 
input of this sort does not require us to take the advised actions, but 
the advice comes from people with a broad perspective on web 
technologies and is worth considering.

First, I would say that several people thought personalization relates 
to their work as well. Some groups have active mandates to support 
personalization in their technologies, particularly Publishing, and 
other groups would see value in it as a solution. Their specific 
personalization use cases may be somewhat different from the ones the 
task force focuses on, but the general idea seemed to resonate. There 
was a clear desire to see personalization evolve in a coordinated way 
across W3C. I think the APA group is the one most suited to drive that 
coordination from the accessibility side. Coordination will help improve 
adoption of personalization in a faster time frame with a more stable 
technology.

Throughout the talk I tried to make clear my view that the specific 
personalization semantics we're developing aren't the only piece of the 
personalization puzzle. Other technologies may be more suited to support 
specific aspects of personalization. For some features, multiple 
approaches might exist. As we coordinate with other groups, we should 
keep that in mind. In some cases, we may encourage technologies to allow 
the vocabulary we're developing to be used in that technology. In other 
cases, we may identify or create features more unique to that technology 
that map to features in our vocabulary. In my own view, we could expect 
a trend to more of the latter approach. We should view that as a win and 
not get overly invested in the specific vocabulary. This is a deliberate 
contrast to how ARIA wound up.

Although there was a fair amount of interest, real-world benefits of 
personalization weren't clear to some people. They suggested that more 
examples of existing or prototype implementations of the concepts would 
be helpful for people to understand the goal we're trying to achieve. I 
referenced a couple, but they aren't really in forms people could use to 
understand it right now. There would be value for us to develop more 
implementation or demonstration in forms that easily show how various 
personalization properties impact the user experience. Of course, we 
should continue to limit our investment in specific technological 
approaches until the technology settles down more.

One reason for this presentation was to talk with other knowledgeable 
people about ways to apply personalization semantics to content. After 
going over the approaches we've been considering, it became clear that 
the Team is skeptical that either RDFa or Microdata are well-suited for 
this application. While it would be possible to apply terms to content 
using either of these metadata languages, it would require several 
attributes, would require user agents to process the attributes in 
context of each other, and would be more difficult to author than 
necessary for the purpose. These metadata languages are better suited to 
describing arbitrary objects outside of browsers but for our purposes a 
syntax that is optimized to describing objects in a browser rendering 
tree is wanted.

There are two ways to use personalization with attributes right now that 
we've explored to some extent. The first is to have an attribute for 
each property, using the aui prefix, as we have in several examples 
already, such as <button aui-action="undo">. This is relatively easy to 
author and process, but requires support from the Web Platform Working 
Group for us to advance this past the proposal stage. If we conclude 
this is the best approach, we can open discussions with them and see 
where it leads us. Making the attributes ARIA attributes is similar from 
an authoring perspective, but I do not think will be supported by the 
ARIA Working Group, so I think pursuing aui attributes is the best first 
direction for this scenario.

A second approach that's been tossed around a bit but not fully explored 
is to create a single attribute, such as "purpose". In this case we'd 
have to cram both properties and values into the attribute, which I find 
less elegant and more difficult to work with, but it's fairly 
straightforward to author and support. One way could be simply 
concatenating property names and values in the attribute, like <button 
purpose=¨action-undo¨>. Another might be to recast the vocabulary into a 
form that does not require values, but simply lists a larger set of 
properties. Continuing the example of the undo action, since "undo" 
isn't a value of other properties, we might just make "undo" a property, 
so <button purpose=¨undo¨>. Or we might make camel case names for 
properties, so "undoAction" in this case, leading to <button 
purpose="undoAction¨>. All these approaches should be semantically 
equivalent, so it's just a matter of picking what people think will be 
easiest to work with.

There was interest from the Team to open this attribute to other groups, 
the way the role attribute was originally intended. We ran into problems 
supporting multiple vocabularies in the role attribute when user agents 
declined to process namespaces in attribute values; the proposal now 
would be to use "hyphenspace" they way we're effectively doing with some 
role attribute values now. In this case AUI properties would start with 
the aui prefix, resulting in <button purpose=¨aui-action-undo¨>, <button 
purpose=¨aui-undo¨>, or <button purpose="aui-undoAction¨> depending on 
the syntax for attributes we pick. Other groups could define other 
prefixes and set up their own values.

The topic of whether to support multiple attributes with an aui prefix, 
or one attribute with a larger set of values, or continue to explore 
general metadata languages, is something we should coordinate with other 
interested groups. This means I don't think we should pick a solid 
direction yet, but should explore the pros and cons of the proposals and 
see where things land. We've started doing this at 
https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content 
and the work can happen in parallel with the ongoing work to develop the 
vocabulary, so don't think should stall us, but does perhaps impact 
finalization timelines. The input from the Team that the attribute model 
is preferred over the metadata model may be welcome news to some and 
constitutes input to a discussion already under way, though we still 
should take that input as advisory rather than prescriptive.

There are a few threads of work we can pick up from all this; I wanted 
to send this summary to the task force first.

Michael