User context properties as key / value pairs ACTION-43

I have proposed a restructuring of the IndieUI User Context properties
proposed by Rich and Andy, to show how they would look as key / value
pairs. This is in the wiki at:

In this first pass, I tried to minimize editorializing on the properties
themselves. The exercise of working on them did raise some questions for
me, and I wanted to take a second pass as a proposed way to address some
of the issues I saw. Meanwhile, I see that James has added some
properties to the editors' draft that probably overlap with some of
these, and a proposal from me that doesn't take that into account might
confuse the issues. But I've run out of time for this week to do that
thorough job, so I thought it would be best to send around the basic
proposal since it's not specifically germane to the actual content, and
to include some very rough notes for future discussion below:

    * some of these properties overlap, when separated this way
    * a lot of properties seem true/false where false = "don't care"; a
      lot are a couple values with a "don't care" default, maybe those
      could be made more similar to each other somehow
    * don't understand the whole set of X in place of Y properties –
      wouldn't it make more sense to express the media the user *does*
      like and say other media should be substituted?
    * Many properties had a supplemented or replaced option, which I
      split into separate values. Maybe those could be true/false and
      the supplement vs replace could be one global option
    * If we allow lists of values, some properties could be conflated
      (e.g., media preference list, language options)
    * Why two values for Flash hazard? If important enough to set a
      preference, strict should be enough – don't need a soft warning


Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail <>
Information Page <>

Received on Friday, 15 March 2013 19:40:04 UTC