[Accessforall] Are common terms a flawed concept?

Andreas Stiegler stiegler at hdm-stuttgart.de
Mon Jun 16 04:12:59 EDT 2014


Heyho Colin and Christophe,

A very fruitful discussion! Allow me to throw some thoughts in :)

I just had a talk with a software developer at the weekend regarding a way
to describe OS- and rendering-independent GUIs without falling back to
abstract description. Either way, one point that came up was imprecision of
stored settings. The problem here is that for some settings, the
"disturbance" of a user does not scale linearly with the mathematical error
you do. For example: A setting that's 3% off can be more annoying as the
same setting being 25% off.

As you described, Colin, we will always have loss of information when moving
over from one application to another. If applications would all use settings
that we can transform in a lossless way, we wouldn't need to do a research
project around it. Yet, if applications use common terms, their very own
settings can become less precise, without even migrating to another app. I
see that as a discouragement for developers to use common terms. Currently
that's not so much of an issue, as the common terms we use are relatively
closely tailored for the applications supported.

Another problem, from a perspective of a software developer, could be that
once you use common terms, you make a promise. Say you support an
enumeration common term. That requires you to - at least - support all the
modes that are in it. I don't know if we have a mechanism planned for
applications to say "ehm, I only support those 2, but not the third". If so,
then we might want to consider moving away from enumerations in general, and
rather have each enumeration value as their own Boolean setting, to allow
apps to ignore/support them more easily.

Best regards,
Andy

-----Original Message-----
From: accessforall-bounces at fluidproject.org
[mailto:accessforall-bounces at fluidproject.org] On Behalf Of Colin Clark
Sent: Friday, December 20, 2013 5:49 PM
To: Christophe Strobbe
Cc: Accessforall at fluidproject. org; GPII Architecture
Subject: Re: [Accessforall] Are common terms a flawed concept?

Hi Christophe,

Thanks for your response. I really appreciate hearing your perspective, and
it sounds like we're getting clearer on the issues here. A few more comments
inline.

On Dec 19, 2013, at 6:17 AM, Christophe Strobbe <strobbe at hdm-stuttgart.de>
wrote:

> During our face-to-face meeting in Madrid, it was even claimed that 
> the SP3 solutions in Cloud4all use only common terms and no 
> application-specific terms. (Quoting from the meeting minutes: "Only 
> common terms are part of this integration phase"
> <https://docs.google.com/document/d/1FFpZxUK7WvYkqr5c1QeXWe9JngMyqSrBD
> xYktHLhah8/edit#heading=h.1urwc3kvsifz>)
> Lastly, some of the SP3 implementers provided only a list of existing 
> common terms when we asked them which terms they would like to see 
> supported in the second pilot phase. This included an organisation 
> that integrates an AT with GPII without having access to that AT's source
code.
> (This situation was rectified last week.) How likely is it that that 
> AT's settings match the common terms and that no application-specific 
> terms are necessary?
> It is when I noticed this misunderstanding about implementing common 
> terms in SP3 that I started thinking about the potential consequences 
> and wrote my original mail.

When people say "uses common terms" or "only common terms are part of this
phase," I think they typically mean "transformations have been written
between common terms and the application's own settings."

I understand your concern about the ambiguity here, but I don't think I'd
read too much into it. I don't think it's an attempt to convince SP3
developers that they need to change their internal formats to common terms.
It is, however, great that our implementers are integrating their
applications, and since common terms and transformations are a critical
piece of infrastructure for integrating with several of our Matchmakers,
it's a good thing that they're "using common terms."

>> The main motivation for common terms is to serve as a "meeting point" 
>> for a diverse community of developers and application vendors. Common 
>> terms represent common ground where we can translate to and from 
>> application-specific representations.
> 
> This is how I have always understood common terms. There is no 
> misunderstanding on my part.

I'm glad we're on the same page.

> Interoperability is the keyword here. We both agree that implementers 
> don't need to implement common terms natively in order to ensure 
> interoperability; they can use their application-specific terms and 
> provide mappings and transformations to common terms.
> My concern is specifically about common terms where the value range 
> consists of enumerated values.
> (a) They would be unattractive to implement natively because that 
> implies that you commit to their value range. (Fortunately, you don't 
> need to support them natively.)
> (b) They can lead to a loss of precision in setting values when you 
> need to convert from an application-specific terms that uses a 
> specific set of enumerated values to a common term that uses a 
> different set of enumerated values and there is simply no good 
> mapping. (This would be a bit like translating colour terms between 
> languages without recourse to RGB or something similar.)
> (c) In theory, they can also lead to a loss of precision when an 
> application-specific term uses a value range based on continuous data 
> (or even simply integers) whereas the common term uses enumerated 
> values. This is something we are currently avoiding by our choice of 
> data types and value ranges for the common terms.

Loss of precision is a consequence of our "personalized anywhere" model of
interoperability in general. A setting for one application may not map
directly to the setting of another, and there's an inevitable lossiness in
the translation process. This issue exists for every Matchmaker, regardless
of what strategy it uses or whether or not it employs common terms to do its
work. Clearly the challenge, and I don't think it's an impossible one, is to
ensure that common terms are structured suitably to avoid the worst cases of
precision loss wherever possible.

The key advantage to common terms and the transformation process is that
it's architecturally transparent. Common terms provide a shared reference
point to discuss the relationship of one solution to another. And with
declarative transformation rules, we have a visible, parseable,
understandable artifact (i.e. a standardized data structure) that represents
the exact nature of the loss--the transformation rules document.

It sounds like there are many cases where what we need is good modelling
practices for common terms. Enumerations, clearly, can raise problems. I
think they're very useful for capturing needs that are familiar to the
user-your high contrast example is a good one-but we also need to ensure
that the finer-grained terms are available as well so that we don't have a
major loss of precision. My tendency, when modelling common terms, would be
to start with the finer-grained representation first. Perhaps we need to do
a better job of that.

I don't see any reason why we can't plan for an extensibility model for
enumerated common terms to ensure that they're not limited to developers as
well. I'd love your feedback and designs for this if you have any specific
ideas on how we can enable this.

Colin
_______________________________________________
Accessforall mailing list
Accessforall at fluidproject.org
http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall



More information about the Accessforall mailing list