Re: User Contexts API design

comments edited in:
> As currently drafted, the User Contexts spec offers a ValueForKey() operation
> that returns a value of type DOMString, which in turn is a string
> representation of a value of an underlying type. The type represented is
> specified in the description of each key.
>
> I see several potential problems with this arrangement.
>
> 1. The string representations are not defined anywhere in the spec (perhaps
> this could be done by referring to an appropriate standard).

Are you talking vocabulary ? If there were one.  There would be value 
for this to be an external vocabulary in my opinion - but where ? I 
originally thought the User Context spec we are working on was to be 
that "standard".  There are several organisations working in the space 
that would like to have "the" standard, some of which I work with.  They 
include IMS, IEEE, ISO/IEC SC36, ISO/IEC SC35. What I do is try to get 
the ones I work with to converge around a single solution with a common 
set of but its a bit like herding cats.  None of these organisations 
have "THE SINGLE VOCAB THAT IS READY NOW" - they are all 2 years away 
from that and looking towards getting the common solution. I wouldn't 
put GPII in this camp because they are more about "supporting machinery" 
(in s software/net infrastructures sense) than vocabularies.  Suggestion 
- what we could do is separate out those parts and put them in the user 
context in a data model part ?

Or did you mean schemas and bindings ?  There are some of those hanging 
around but we might need to tweak them to match the model we finally 
come up with.

>
> 2. The type of the return value can only be checked at run-time; there is no
> compile-time type checking available.

Is this the same point as 1. ?  If there was a defined vocabulary/data 
model and schemas of some kind that enabled the compile time checking 
would this answer the point ?  Organisations I work with are moving 
towards json bindings of preferences that need to be validated - again 
as I understand it there are a mixture of technologies that can be 
applied to this, some better than others.  I built a validator for the 
IMS AfA 3 data model but our model is changing and it wasn't sufficient.

Another project I'm working with that is implementing preferences, which 
I mention in passing here for future potential links is an IEEE R&D 
project (http://www.ieee-adb.org/) which is looking at the application 
of preferences to EPUB3 - we might squeeze some implementation work out 
of them at a suitable point.  The validation requirement there will need 
to be very tight to work in the business cases they have in mind. I 
mention this *only* in case its useful (not doing a personal or 
standards-organisation sales job) - I think its really important to try 
to keep people working in this particular space collaborating on *one* 
solution and with *one* set of data model content (i.e. the same or 
interoperable preferences).

end-of-andy's comments

andy

> 3. Every access to a return value requires a type conversion from DOMString to
> the appropriate type.
>
> Alternatives
>
> a. Use a union type as the return value. This avoids conversions, presumably,
> but it doesn't provide good type checking. It also constrains the available
> types in advance, of course.
>
> b. Define an operation for each key and group the different categories of keys into
> interfaces appropriately, i.e., each query would be a method call and a value
> of the appropriate type would be returned in each case.
>
> Other options?
>
> Error handling should also be considered, including the case in which the
> value isn't available because the user has denied permission to retrieve it.
> Perhaps the solution here is to define an exception (I've been looking at
> WebIDL, which provides for these).
>
>
>




andy
andyheath@axelrod.plus.com
-- 
__________________
Andy Heath
http://axelafa.com

Received on Tuesday, 4 June 2013 10:11:19 UTC