Re: User contexts submission - general comments

Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> 
> Hi Jason,

Hi Rich,
> 
> Good to be working with you again. I am in your neck of the woods, Sydney,
> Australia, this week but have limited access to email. 

It's a welcome privilege to work with you, as always. I hope the visit to
Australia is highly successful and productive.

> We can work to get you use cases from IMS but keep in mind we do not want
> to reproduce 8 years of work and implementations for this effort. There is
> tremendous value in reusing what has already been established. Furthermore,
> the U.S. Department of Education is looking to adopt APIP and AccessForAll
> so we have industry uptake. It is understood that we need to expand on the
> vocabulary, ... particularly for device capabilities such as touch devices.

That all seems entirely reasonable. Having the use cases at hand should help,
though, when the discussion arises as to what should or shouldn't be included.
I agree that harmonization of standards is very desirable and that duplication
of effort is to be discouraged. On the other hand, I would be rather surprised
if this vocabulary (suitably expanded) could work its way through the W3C
process without a detailed and possibly controversial discussion of the design
along the way, and that's where it seems important to have a good grasp of the
problems intended to be addressed. I might be wrong, of course (about
specification development processes), and it could be that having an existing
vocabulary from elsewhere that is widely seen to solve the problems could
simplify the discussion considerably.

I hope this clarifies what the underlying concern was. Of course, if there is
general support for adopting an existing vocabulary (suitably
extended for touch devices) and existing implementation experience to
accompany it, then that's entirely appropriate as the basis of the spec.
> 
> The API should have the ability to get properties, and be notified of
> context changes. Although we can prototype with a plug-in we also need to
> have the browser be able to adjust the properties based on situational
> changes such as noisy areas.

That's a good case for including a requirement that the API support property
adjustment, so there won't be any disagreement from me on that point.

Received on Monday, 13 August 2012 01:24:57 UTC