Thread Subject: Concerns about our current definition of a "platform"

Return to this mailing list's archives

From: Peter Korn
Date: Mon, Aug 20 2007 6:30 PM
Subject: Concerns about our current definition of a "platform"

From a meeting or two ago, I took the action to try to update our
current draft definition of a "platform". You can find that definition
at
http://teitac.org/wiki/Web_and_Software:_Definitions#In_process_definitions.

Here is the text:

--------------------------

*Platform software*:
collection of software components that runs on an underlying software or
hardware layer, such that the platform creates a virtual environment in
which to run applications in a manner which isolates the applications
from the underlying layer.

* Note 1: If there is a direct route from the application to the
underlying layer then the software components in the middle are
not considered to be a "platform". For example, a program which
hosts plug-in's is not a platform if the plug-in can directly
access the underlying layer.
* Note 2: An application offering a compute service, such as a 3d
rendering engine where a requesting application can directly
access the underlying layer would also not be considered a
"platform".
* Note 3: A particular software component may play the role of a
platform in some situations and not in others. Platforms can
include such things as Internet browsers, operating systems,
plug-ins to internet browsers or other software applications, and
under some situations, byte-code interpreted virtual environments,
and other "programming within another programming" environments.
* *TBD:* Notes about bootloader programs and closed systems?

-------------------------

My concern is with the phrase "in a manner which isolates the
application from the underlying layer", and especially Note 1 "If there
is a direct route from the application to the underlying layer...".

I believe the Java platform should meet our definition of a platform.
As per note 3, the Java runtime interprets Java byte-code, and runs the
code inside a virtual, run-time environment. However, it is possible to
introduce native code which can be called directly from Java (via the
"Java Native Interface" mechanism or JNI) - thus creating "a direct
route from the application to the underlying layer". Should the
possibility of the creation of such a direct route disqualify Java as a
platform (even if it isn't used; or it is used for something completely
unrelated to presenting an accessible user interface: e.g. fast file
manipulation or database access)? Likewise, one of the things we've
done in the Swing user interface library for Java is gather and expose
platform-specific settings for things like the desktop font and color
and menu height - all of the things necessary to make visual user
interface that complies with the desktop theme setting. In a sense
then, with this information, we are expressly allowing Java applications
to behave as if they are visually identical to native application -
dynamically and instantly updating their look & feel as the user changes
the desktop setting (which doesn't appear to be isolation at all). And
in fact, I suggest that this is exactly what we want a well behaved
platform-that-is-also-an-application to do.

Oh, and as far as the TBD goes; I don't know that we need to explicitly
mention bootloaders here. They aren't generally implemented as a
platform (hmmm... I guess we could just note that and be done with it).


Therefore, I suggest we update our definition to address this example,
and propose this draft:


*Platform software*:
collection of software components that runs on an underlying software or
hardware layer, and that provides a set of software services to
applications which allows them to be isolated from the underlying
software or hardware layer.

* Note 1: For our purposes, it is those software components/services
provided to applications for the creation or manipulation of user
interfaces and user input - that impact accessibility - which are
of concern for whether something is a platform or not. An
application offering a compute service, such as a 3d rendering
engine where a requesting application isn't using the software
components/services to create a user interface and interact with
the user, should not be considered a "platform".
* Note 2: If applications typically connect directly to the
underlying layer, rather than relying solely on the platform
software components and services, then it is likely that the
software components in the middle are not acting as a "platform".
For example, a program which hosts plug-in's is not a platform if
the plug-in can directly access the underlying layer.
* Note 3: A particular software component may play the role of a
platform in some situations and not in others. Platforms can
include such things as Internet browsers, operating systems,
plug-ins to internet browsers or other software applications, and
under some situations, byte-code interpreted virtual environments,
and other "programming within another programming" environments.



Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Gregg Vanderheiden
Date: Mon, Aug 20 2007 8:20 PM
Subject: Re: Concerns about our current definition of a"platform"

Thanks Peter


Perhaps we should allow for things that act as platform for some aspects but
not for others. It is mentioned in note 3 but it should be allowed for in
the provision language as well.

See edits below.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.


>
> *Platform software*:
> collection of software components that runs on an underlying
> software or hardware layer, such that the platform creates a
> virtual environment in which to run applications in a manner
> which isolates the applications PARTIALLY OR ENTIRELY from the underlying
layer.
>
> * Note 1: If there is a direct route from the application to the
> underlying layer then the software components in the middle are
> not ACTING AS a "platform" FOR THOSE ASPECTS OF THE APPLICATION.
For example, a program which
> hosts plug-in's is not ACTING AS a platform if the plug-in can
directly
> access the underlying layer.
> * Note 2: An application offering a compute service, such as a 3d
> rendering engine where a requesting application can directly
> access the underlying layer would also not be considered a
> "platform".
> * Note 3: A particular software component may play the role of a
> platform in some situations and not in others. Platforms can
> include such things as Internet browsers, operating systems,
> plug-ins to internet browsers or other software
> applications, and
> under some situations, byte-code interpreted virtual
> environments,
> and other "programming within another programming" environments.
> * *TBD:* Notes about bootloader programs and closed systems?
>
> -------------------------
>
> My concern is with the phrase "in a manner which isolates the
> application from the underlying layer", and especially Note 1
> "If there is a direct route from the application to the
> underlying layer...".
>
> I believe the Java platform should meet our definition of a
> platform.
> As per note 3, the Java runtime interprets Java byte-code,
> and runs the code inside a virtual, run-time environment.
> However, it is possible to introduce native code which can be
> called directly from Java (via the "Java Native Interface"
> mechanism or JNI) - thus creating "a direct route from the
> application to the underlying layer". Should the possibility
> of the creation of such a direct route disqualify Java as a
> platform (even if it isn't used; or it is used for something
> completely unrelated to presenting an accessible user
> interface: e.g. fast file manipulation or database access)?
> Likewise, one of the things we've done in the Swing user
> interface library for Java is gather and expose
> platform-specific settings for things like the desktop font
> and color and menu height - all of the things necessary to
> make visual user interface that complies with the desktop
> theme setting. In a sense then, with this information, we
> are expressly allowing Java applications to behave as if they
> are visually identical to native application - dynamically
> and instantly updating their look & feel as the user changes
> the desktop setting (which doesn't appear to be isolation at
> all). And in fact, I suggest that this is exactly what we
> want a well behaved platform-that-is-also-an-application to do.
>
> Oh, and as far as the TBD goes; I don't know that we need to
> explicitly mention bootloaders here. They aren't generally
> implemented as a platform (hmmm... I guess we could just note
> that and be done with it).
>
>
> Therefore, I suggest we update our definition to address this
> example, and propose this draft:
>
>
> *Platform software*:
> collection of software components that runs on an underlying
> software or
> hardware layer, and that provides a set of software services to
> applications which allows them to be isolated from the underlying
> software or hardware layer.
>
> * Note 1: For our purposes, it is those software
> components/services
> provided to applications for the creation or
> manipulation of user
> interfaces and user input - that impact accessibility -
> which are
> of concern for whether something is a platform or not. An
> application offering a compute service, such as a 3d rendering
> engine where a requesting application isn't using the software
> components/services to create a user interface and interact with
> the user, should not be considered a "platform".
> * Note 2: If applications typically connect directly to the
> underlying layer, rather than relying solely on the platform
> software components and services, then it is likely that the
> software components in the middle are not acting as a
> "platform".
> For example, a program which hosts plug-in's is not a
> platform if
> the plug-in can directly access the underlying layer.
> * Note 3: A particular software component may play the role of a
> platform in some situations and not in others. Platforms can
> include such things as Internet browsers, operating systems,
> plug-ins to internet browsers or other software
> applications, and
> under some situations, byte-code interpreted virtual
> environments,
> and other "programming within another programming" environments.
>
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

From: Peter Korn
Date: Mon, Aug 20 2007 9:00 PM
Subject: Re: Concerns about our current definition of a"platform"

Gregg,

You provided edits to the version in the 17Aug draft, not to the
proposal I put forth. Was that your intention? The key for me is what
the platform provides that defines it as a platform (with what the bulk
of applications use cementing that definition or countering it). With
such a definition, we can then place requirements on anything that is a
platform (by that definition).

Going into "partially", and "acting as", and "for those aspects of an
application" complicates matters significantly. And I don't see what we
gain by doing that. If something is trying to be a platform, then it
should obey the platform rules.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Thanks Peter
>
>
> Perhaps we should allow for things that act as platform for some aspects but
> not for others. It is mentioned in note 3 but it should be allowed for in
> the provision language as well.
>
> See edits below.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> *Platform software*:
>> collection of software components that runs on an underlying
>> software or hardware layer, such that the platform creates a
>> virtual environment in which to run applications in a manner
>> which isolates the applications PARTIALLY OR ENTIRELY from the underlying
>>
> layer.
>
>> * Note 1: If there is a direct route from the application to the
>> underlying layer then the software components in the middle are
>> not ACTING AS a "platform" FOR THOSE ASPECTS OF THE APPLICATION.
>>
> For example, a program which
>
>> hosts plug-in's is not ACTING AS a platform if the plug-in can
>>
> directly
>
>> access the underlying layer.
>> * Note 2: An application offering a compute service, such as a 3d
>> rendering engine where a requesting application can directly
>> access the underlying layer would also not be considered a
>> "platform".
>> * Note 3: A particular software component may play the role of a
>> platform in some situations and not in others. Platforms can
>> include such things as Internet browsers, operating systems,
>> plug-ins to internet browsers or other software
>> applications, and
>> under some situations, byte-code interpreted virtual
>> environments,
>> and other "programming within another programming" environments.
>> * *TBD:* Notes about bootloader programs and closed systems?
>>
>> -------------------------
>>
>> My concern is with the phrase "in a manner which isolates the
>> application from the underlying layer", and especially Note 1
>> "If there is a direct route from the application to the
>> underlying layer...".
>>
>> I believe the Java platform should meet our definition of a
>> platform.
>> As per note 3, the Java runtime interprets Java byte-code,
>> and runs the code inside a virtual, run-time environment.
>> However, it is possible to introduce native code which can be
>> called directly from Java (via the "Java Native Interface"
>> mechanism or JNI) - thus creating "a direct route from the
>> application to the underlying layer". Should the possibility
>> of the creation of such a direct route disqualify Java as a
>> platform (even if it isn't used; or it is used for something
>> completely unrelated to presenting an accessible user
>> interface: e.g. fast file manipulation or database access)?
>> Likewise, one of the things we've done in the Swing user
>> interface library for Java is gather and expose
>> platform-specific settings for things like the desktop font
>> and color and menu height - all of the things necessary to
>> make visual user interface that complies with the desktop
>> theme setting. In a sense then, with this information, we
>> are expressly allowing Java applications to behave as if they
>> are visually identical to native application - dynamically
>> and instantly updating their look & feel as the user changes
>> the desktop setting (which doesn't appear to be isolation at
>> all). And in fact, I suggest that this is exactly what we
>> want a well behaved platform-that-is-also-an-application to do.
>>
>> Oh, and as far as the TBD goes; I don't know that we need to
>> explicitly mention bootloaders here. They aren't generally
>> implemented as a platform (hmmm... I guess we could just note
>> that and be done with it).
>>
>>
>> Therefore, I suggest we update our definition to address this
>> example, and propose this draft:
>>
>>
>> *Platform software*:
>> collection of software components that runs on an underlying
>> software or
>> hardware layer, and that provides a set of software services to
>> applications which allows them to be isolated from the underlying
>> software or hardware layer.
>>
>> * Note 1: For our purposes, it is those software
>> components/services
>> provided to applications for the creation or
>> manipulation of user
>> interfaces and user input - that impact accessibility -
>> which are
>> of concern for whether something is a platform or not. An
>> application offering a compute service, such as a 3d rendering
>> engine where a requesting application isn't using the software
>> components/services to create a user interface and interact with
>> the user, should not be considered a "platform".
>> * Note 2: If applications typically connect directly to the
>> underlying layer, rather than relying solely on the platform
>> software components and services, then it is likely that the
>> software components in the middle are not acting as a
>> "platform".
>> For example, a program which hosts plug-in's is not a
>> platform if
>> the plug-in can directly access the underlying layer.
>> * Note 3: A particular software component may play the role of a
>> platform in some situations and not in others. Platforms can
>> include such things as Internet browsers, operating systems,
>> plug-ins to internet browsers or other software
>> applications, and
>> under some situations, byte-code interpreted virtual
>> environments,
>> and other "programming within another programming" environments.
>>
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>

From: Gregg Vanderheiden
Date: Mon, Aug 20 2007 10:05 PM
Subject: Re: Concerns about our current definition of a"platform"

Yes - I did edit old version.

Nope - not intentional.

Comments below. (marked GV:)





Gregg

-- ------------------------------

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf

> Of Peter Korn

> Sent: Monday, August 20, 2007 9:55 PM

> To: TEITAC Web/Software Subcommittee

> Subject: Re: [teitac-websoftware] Concerns about our current

> definition of a"platform"

>

> Gregg,

>

> You provided edits to the version in the 17Aug draft, not to

> the proposal I put forth. Was that your intention?



GV: Yes I did - but not intentionally.



The key

> for me is what the platform provides that defines it as a

> platform (with what the bulk of applications use cementing

> that definition or countering it).



GV: Agree



With such a definition,

> we can then place requirements on anything that is a platform

> (by that definition).



GV: Don't follow that. What I edited into the provision was just an
admission that some things serve as partial platforms. And that is in note
3



>

> Going into "partially", and "acting as", and "for those

> aspects of an application" complicates matters significantly.

> And I don't see what we gain by doing that. If something is

> trying to be a platform, then it should obey the platform rules.

>



GV: Again - don't follow. Your note 3 below says the same thing. But by
not having anything to that effect in the provision - the note contradicts
the provision.





Your new draft is below -- with edits



*Platform software*:

collection of software components that runs on an underlying software or

hardware layer, and that provides a set of software services to

applications which allows them to be isolated, partially or completely,
from the underlying software or hardware layer.



* Note 1: For our purposes, it is those software components/services

provided to applications for the creation or manipulation of user

interfaces and user input - and that impact accessibility - that are

of concern for whether something is a platform or not. An

application offering a compute service, such as a 3d rendering

engine where a requesting application isn't using the software

components/services to create a user interface and interact with

the user, should not be considered to be acting as a "platform".

* Note 2: If applications typically connect directly to the

underlying layer, rather than relying solely on the platform

software components and services, then it is likely that the

software components in the middle are not acting as a "platform".

For example, a program which hosts plug-in's is not a platform if

the plug-in can directly access the underlying layer.

* Note 3: A particular software component may play the role of a

platform in some situations and not in others. Platforms can

include such things as Internet browsers, operating systems,

plug-ins to internet browsers or other software applications, and

under some situations, byte-code interpreted virtual environments,

and other "programming within another programming" environments.

From: Peter Korn
Date: Mon, Aug 20 2007 10:30 PM
Subject: Re: Concerns about our current definition of a"platform"

Hi Gregg,

I know that Sean had some concerns about the platform definition, and I
believe language around isolation and the explicit note about browser
plug-ins not constituting a platform came from him. When you say
"partially", you open potentially a big hole, sweeping into the platform
definitions things that only vaguely partially provide some software
components/services but that really shouldn't be seen as a platform. By
doing so, you subject a lot more things to the platform rule(s) for
which I think they really shouldn't apply.

Can you provide some specific examples of things you feel are platforms,
that can only be considered platforms with your language additions?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Yes - I did edit old version.
>
> Nope - not intentional.
>
> Comments below. (marked GV:)
>
> Gregg
>
> -- ------------------------------
>
> Gregg C Vanderheiden Ph.D.
>
> > -----Original Message-----
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>
> > Of Peter Korn
>
> > Sent: Monday, August 20, 2007 9:55 PM
>
> > To: TEITAC Web/Software Subcommittee
>
> > Subject: Re: [teitac-websoftware] Concerns about our current
>
> > definition of a"platform"
>
> >
>
> > Gregg,
>
> >
>
> > You provided edits to the version in the 17Aug draft, not to
>
> > the proposal I put forth. Was that your intention?
>
> GV: Yes I did - but not intentionally.
>
> The key
>
> > for me is what the platform provides that defines it as a
>
> > platform (with what the bulk of applications use cementing
>
> > that definition or countering it).
>
> GV: Agree
>
> With such a definition,
>
> > we can then place requirements on anything that is a platform
>
> > (by that definition).
>
> GV: Don't follow that. What I edited into the provision was just an
> admission that some things serve as partial platforms. And that is in
> note 3
>
> >
>
> > Going into "partially", and "acting as", and "for those
>
> > aspects of an application" complicates matters significantly.
>
> > And I don't see what we gain by doing that. If something is
>
> > trying to be a platform, then it should obey the platform rules.
>
> >
>
> GV: Again - don't follow. Your note 3 below says the same thing. But
> by not having anything to that effect in the provision - the note
> contradicts the provision.
>
> Your new draft is below -- with edits
>
> *Platform software*:
>
> collection of software components that runs on an underlying software or
>
> hardware layer, and that provides a set of software services to
>
> applications which allows them to be isolated, partially or
> completely, from the underlying software or hardware layer.
>
> * Note 1: For our purposes, it is those software components/services
>
> provided to applications for the creation or manipulation of user
>
> interfaces and user input – and that impact accessibility – that are
>
> of concern for whether something is a platform or not. An
>
> application offering a compute service, such as a 3d rendering
>
> engine where a requesting application isn't using the software
>
> components/services to create a user interface and interact with
>
> the user, should not be considered to be acting as a "platform".
>
> * Note 2: If applications typically connect directly to the
>
> underlying layer, rather than relying solely on the platform
>
> software components and services, then it is likely that the
>
> software components in the middle are not acting as a "platform".
>
> For example, a program which hosts plug-in's is not a platform if
>
> the plug-in can directly access the underlying layer.
>
> * Note 3: A particular software component may play the role of a
>
> platform in some situations and not in others. Platforms can
>
> include such things as Internet browsers, operating systems,
>
> plug-ins to internet browsers or other software applications, and
>
> under some situations, byte-code interpreted virtual environments,
>
> and other "programming within another programming" environments.
>
> ------------------------------------------------------------------------
>
>

From: Gregg Vanderheiden
Date: Mon, Aug 20 2007 11:10 PM
Subject: Re: Concerns about our current definition of a"platform"

Web browsers.

You include them as platform in a note (3) - but not in the language of the
definition. If they aren't platform by the definition language they can't be
made into platform in a note. Notes can explain but not extend or limit
the definition.

I don't have a religious thing about this so you can define it as you like.
I was just trying to make it clean and point out the inconsistency. If you
still have questions I suggest we take it off list to resolve since I think
we are both in the same place but just trying to work out consistent
wording. Don't want to use up listserve bandwidth on wordsmithing where
both people agree on desired outcome.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Monday, August 20, 2007 11:26 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current
> definition of a"platform"
>
> Hi Gregg,
>
> I know that Sean had some concerns about the platform
> definition, and I believe language around isolation and the
> explicit note about browser plug-ins not constituting a
> platform came from him. When you say "partially", you open
> potentially a big hole, sweeping into the platform
> definitions things that only vaguely partially provide some
> software components/services but that really shouldn't be
> seen as a platform. By doing so, you subject a lot more
> things to the platform rule(s) for which I think they really
> shouldn't apply.
>
> Can you provide some specific examples of things you feel are
> platforms, that can only be considered platforms with your
> language additions?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
> > Yes - I did edit old version.
> >
> > Nope - not intentional.
> >
> > Comments below. (marked GV:)
> >
> > Gregg
> >
> > -- ------------------------------
> >
> > Gregg C Vanderheiden Ph.D.
> >
> > > -----Original Message-----
> >
> > > From: = EMAIL ADDRESS REMOVED =
> >
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> >
> > > Of Peter Korn
> >
> > > Sent: Monday, August 20, 2007 9:55 PM
> >
> > > To: TEITAC Web/Software Subcommittee
> >
> > > Subject: Re: [teitac-websoftware] Concerns about our current
> >
> > > definition of a"platform"
> >
> > >
> >
> > > Gregg,
> >
> > >
> >
> > > You provided edits to the version in the 17Aug draft, not to
> >
> > > the proposal I put forth. Was that your intention?
> >
> > GV: Yes I did - but not intentionally.
> >
> > The key
> >
> > > for me is what the platform provides that defines it as a
> >
> > > platform (with what the bulk of applications use cementing
> >
> > > that definition or countering it).
> >
> > GV: Agree
> >
> > With such a definition,
> >
> > > we can then place requirements on anything that is a platform
> >
> > > (by that definition).
> >
> > GV: Don't follow that. What I edited into the provision was just an
> > admission that some things serve as partial platforms. And
> that is in
> > note 3
> >
> > >
> >
> > > Going into "partially", and "acting as", and "for those
> >
> > > aspects of an application" complicates matters significantly.
> >
> > > And I don't see what we gain by doing that. If something is
> >
> > > trying to be a platform, then it should obey the platform rules.
> >
> > >
> >
> > GV: Again - don't follow. Your note 3 below says the same
> thing. But
> > by not having anything to that effect in the provision - the note
> > contradicts the provision.
> >
> > Your new draft is below -- with edits
> >
> > *Platform software*:
> >
> > collection of software components that runs on an
> underlying software or
> >
> > hardware layer, and that provides a set of software services to
> >
> > applications which allows them to be isolated, partially or
> > completely, from the underlying software or hardware layer.
> >
> > * Note 1: For our purposes, it is those software components/services
> >
> > provided to applications for the creation or manipulation of user
> >
> > interfaces and user input - and that impact accessibility - that are
> >
> > of concern for whether something is a platform or not. An
> >
> > application offering a compute service, such as a 3d rendering
> >
> > engine where a requesting application isn't using the software
> >
> > components/services to create a user interface and interact with
> >
> > the user, should not be considered to be acting as a "platform".
> >
> > * Note 2: If applications typically connect directly to the
> >
> > underlying layer, rather than relying solely on the platform
> >
> > software components and services, then it is likely that the
> >
> > software components in the middle are not acting as a "platform".
> >
> > For example, a program which hosts plug-in's is not a platform if
> >
> > the plug-in can directly access the underlying layer.
> >
> > * Note 3: A particular software component may play the role of a
> >
> > platform in some situations and not in others. Platforms can
> >
> > include such things as Internet browsers, operating systems,
> >
> > plug-ins to internet browsers or other software applications, and
> >
> > under some situations, byte-code interpreted virtual environments,
> >
> > and other "programming within another programming" environments.
> >
> >
> --------------------------------------------------------------
> ----------
> >
> >

From: Sean Hayes
Date: Tue, Aug 21 2007 3:35 AM
Subject: Re: Concerns about our current definition of a "platform"

Peter,

I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform

Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.

If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.

We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.

If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.

Thanks,

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

From: Peter Korn
Date: Tue, Aug 21 2007 9:10 AM
Subject: Re: Concerns about our current definition of a "platform"

Sean,

Here I disagree. I believe it is a matter of design and intention, not
theoretical possibility. Only a very tiny percentage of Java
applications use JNI to call directly to the underlying system. And in
those cases, they almost never do so for generating user interfaces.
That fact that it is a possibility doesn't remove the burden from the
Java platform from providing the accessibility support that we believe
is the responsibility of platforms to provide. A key "value
proposition" of the Java platform is that you can write an application
that runs on Windows & Macintosh & Solaris & Linux & ..., without
modification or even recompilation. The only way to deliver that value
proposition is if the platform provides everything necessary for
isolation (not whether any particular application uses that isolation).

This is distinct from what any application written for the Java platform
does or does not do. As you note, because it is possible to use JNI to
make native calls to the underlying platform, it is possible for Java
application to bind itself to the Macintosh directly (or to Solaris, or
Windows), and to use underlying platform calls to generate a user
interface, etc. Such an application could even make Cocoa accessibility
API calls (or AT-SPI, or UI Automation, or ...); doing so would be a way
for that application to meet our draft 508 requirements.

But what we are (I think) trying to do is ensure that such an
application can meet the 508 requirements *without* needing to resort to
such underlying-platform-specific means; that instead it can rely on the
immediately platform - the "middle platform" if you will. It can only
do that if that middle platform is following a set of rules, and
providing the necessary accessibility infrastructure/support.


The key challenge for us in writing this language, I believe, is to
capture platforms that are attempting to be platforms and that are
attempting to provide a rich suite of services that allow for isolation
from the underlying platform; and leave out software services layers
that aren't attempting to be such platforms, that aren't attempting to
allow for such a level of isolation.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. to carry forward your analogy: being isolated is like being
pregnant; having the potential to offer isolation is like having a
functioning womb. We are putting requirements on wombs so that
gestating babies can make use of an accessible womb without having to
come out into the larger world to do so.

> Peter,
>
> I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform
>
> Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.
>
> If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.
>
> We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.
>
> If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.
>
> Thanks,
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
>

From: Sean Hayes
Date: Tue, Aug 21 2007 10:35 AM
Subject: Re: Concerns about our current definition of a "platform"

But the problem is you can't put an intention into a ruling.

I agree that for the most part authors do not use JNI, or equivalents all the time; but it is possible, and that API is there for a reason. Thus applications written for the full Java runtime are (potentially) exposed to two layers of software services. The issue is to create language that would encourage on the one hand that a relatively complete runtime like Java provide the services, but which would not require other less complete software services to provide them when they can adequately rely on the underlying platform services.

If we allow your weaker form of definition of platform, perhaps we can modify 3W into two provisions, to be a little more flexible as follows


3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:

1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.

Software that is both a 'platform', and an 'application' running on another platform must either provide this access within the platform itself, or allow applications direct access to the underlying platform. Platforms that are intended to create substantially complete environments, but which also allow access to the underlying platform in a controlled manner, should provide this functionality within the platform.

3 W (b) Software that is both a 'platform', and an 'application' running on another platform must provide mechanisms for moving the keyboard focus into and out of an application, and addressing central conflicts between keyboard mnemonics in the application and the host platform.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 21 August 2007 16:04
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"

Sean,

Here I disagree. I believe it is a matter of design and intention, not
theoretical possibility. Only a very tiny percentage of Java
applications use JNI to call directly to the underlying system. And in
those cases, they almost never do so for generating user interfaces.
That fact that it is a possibility doesn't remove the burden from the
Java platform from providing the accessibility support that we believe
is the responsibility of platforms to provide. A key "value
proposition" of the Java platform is that you can write an application
that runs on Windows & Macintosh & Solaris & Linux & ..., without
modification or even recompilation. The only way to deliver that value
proposition is if the platform provides everything necessary for
isolation (not whether any particular application uses that isolation).

This is distinct from what any application written for the Java platform
does or does not do. As you note, because it is possible to use JNI to
make native calls to the underlying platform, it is possible for Java
application to bind itself to the Macintosh directly (or to Solaris, or
Windows), and to use underlying platform calls to generate a user
interface, etc. Such an application could even make Cocoa accessibility
API calls (or AT-SPI, or UI Automation, or ...); doing so would be a way
for that application to meet our draft 508 requirements.

But what we are (I think) trying to do is ensure that such an
application can meet the 508 requirements *without* needing to resort to
such underlying-platform-specific means; that instead it can rely on the
immediately platform - the "middle platform" if you will. It can only
do that if that middle platform is following a set of rules, and
providing the necessary accessibility infrastructure/support.


The key challenge for us in writing this language, I believe, is to
capture platforms that are attempting to be platforms and that are
attempting to provide a rich suite of services that allow for isolation
from the underlying platform; and leave out software services layers
that aren't attempting to be such platforms, that aren't attempting to
allow for such a level of isolation.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. to carry forward your analogy: being isolated is like being
pregnant; having the potential to offer isolation is like having a
functioning womb. We are putting requirements on wombs so that
gestating babies can make use of an accessible womb without having to
come out into the larger world to do so.

> Peter,
>
> I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform
>
> Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.
>
> If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.
>
> We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.
>
> If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.
>
> Thanks,
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
>

From: Peter Korn
Date: Tue, Aug 21 2007 2:50 PM
Subject: Re: Concerns about our current definition of a "platform"

Hi Sean,

We are getting closer I think, but not there yet.

Your 3-W(a)(1) and (2) essentially presume apps shall have direct access
to the underlying platform. That is not a good assumption. I like your
language "platforms that are intended to create substantially complete
environments... should provide this functionality within the platform".
Then, platforms that don't do this must allow applications running on
them to take the route described in 3-W(a)(1) and (2).

How about a different tack - bring in your phrase "intended to create
substantially complete environments" into the platform definition?

You said "you can't put an intention into a ruling", but that is
essentially what you did in your language. Why not use it in the
definition?


Regards,


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> But the problem is you can't put an intention into a ruling.
>
> I agree that for the most part authors do not use JNI, or equivalents all the time; but it is possible, and that API is there for a reason. Thus applications written for the full Java runtime are (potentially) exposed to two layers of software services. The issue is to create language that would encourage on the one hand that a relatively complete runtime like Java provide the services, but which would not require other less complete software services to provide them when they can adequately rely on the underlying platform services.
>
> If we allow your weaker form of definition of platform, perhaps we can modify 3W into two provisions, to be a little more flexible as follows
>
>
> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>
> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.
>
> Software that is both a 'platform', and an 'application' running on another platform must either provide this access within the platform itself, or allow applications direct access to the underlying platform. Platforms that are intended to create substantially complete environments, but which also allow access to the underlying platform in a controlled manner, should provide this functionality within the platform.
>
> 3 W (b) Software that is both a 'platform', and an 'application' running on another platform must provide mechanisms for moving the keyboard focus into and out of an application, and addressing central conflicts between keyboard mnemonics in the application and the host platform.
>
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: 21 August 2007 16:04
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"
>
> Sean,
>
> Here I disagree. I believe it is a matter of design and intention, not
> theoretical possibility. Only a very tiny percentage of Java
> applications use JNI to call directly to the underlying system. And in
> those cases, they almost never do so for generating user interfaces.
> That fact that it is a possibility doesn't remove the burden from the
> Java platform from providing the accessibility support that we believe
> is the responsibility of platforms to provide. A key "value
> proposition" of the Java platform is that you can write an application
> that runs on Windows & Macintosh & Solaris & Linux & ..., without
> modification or even recompilation. The only way to deliver that value
> proposition is if the platform provides everything necessary for
> isolation (not whether any particular application uses that isolation).
>
> This is distinct from what any application written for the Java platform
> does or does not do. As you note, because it is possible to use JNI to
> make native calls to the underlying platform, it is possible for Java
> application to bind itself to the Macintosh directly (or to Solaris, or
> Windows), and to use underlying platform calls to generate a user
> interface, etc. Such an application could even make Cocoa accessibility
> API calls (or AT-SPI, or UI Automation, or ...); doing so would be a way
> for that application to meet our draft 508 requirements.
>
> But what we are (I think) trying to do is ensure that such an
> application can meet the 508 requirements *without* needing to resort to
> such underlying-platform-specific means; that instead it can rely on the
> immediately platform - the "middle platform" if you will. It can only
> do that if that middle platform is following a set of rules, and
> providing the necessary accessibility infrastructure/support.
>
>
> The key challenge for us in writing this language, I believe, is to
> capture platforms that are attempting to be platforms and that are
> attempting to provide a rich suite of services that allow for isolation
> from the underlying platform; and leave out software services layers
> that aren't attempting to be such platforms, that aren't attempting to
> allow for such a level of isolation.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> P.S. to carry forward your analogy: being isolated is like being
> pregnant; having the potential to offer isolation is like having a
> functioning womb. We are putting requirements on wombs so that
> gestating babies can make use of an accessible womb without having to
> come out into the larger world to do so.
>
>
>> Peter,
>>
>> I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform
>>
>> Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.
>>
>> If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.
>>
>> We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.
>>
>> If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.
>>
>> Thanks,
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>>
>>

From: Sean Hayes
Date: Tue, Aug 21 2007 3:10 PM
Subject: Re: Concerns about our current definition of a "platform"

The difference is the 'intended' part I used is in a should, rather than a shall phrase. If we put it in the definition it becomes a shall again.

I'm not sure why you think I presume they shall have direct access, I created the or, so direct access is only an option if the platform is not interveneing. Perhaps you could elaborate what you mean?

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 21 August 2007 21:42
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"

Hi Sean,

We are getting closer I think, but not there yet.

Your 3-W(a)(1) and (2) essentially presume apps shall have direct access
to the underlying platform. That is not a good assumption. I like your
language "platforms that are intended to create substantially complete
environments... should provide this functionality within the platform".
Then, platforms that don't do this must allow applications running on
them to take the route described in 3-W(a)(1) and (2).

How about a different tack - bring in your phrase "intended to create
substantially complete environments" into the platform definition?

You said "you can't put an intention into a ruling", but that is
essentially what you did in your language. Why not use it in the
definition?


Regards,


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> But the problem is you can't put an intention into a ruling.
>
> I agree that for the most part authors do not use JNI, or equivalents all the time; but it is possible, and that API is there for a reason. Thus applications written for the full Java runtime are (potentially) exposed to two layers of software services. The issue is to create language that would encourage on the one hand that a relatively complete runtime like Java provide the services, but which would not require other less complete software services to provide them when they can adequately rely on the underlying platform services.
>
> If we allow your weaker form of definition of platform, perhaps we can modify 3W into two provisions, to be a little more flexible as follows
>
>
> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>
> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.
>
> Software that is both a 'platform', and an 'application' running on another platform must either provide this access within the platform itself, or allow applications direct access to the underlying platform. Platforms that are intended to create substantially complete environments, but which also allow access to the underlying platform in a controlled manner, should provide this functionality within the platform.
>
> 3 W (b) Software that is both a 'platform', and an 'application' running on another platform must provide mechanisms for moving the keyboard focus into and out of an application, and addressing central conflicts between keyboard mnemonics in the application and the host platform.
>
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: 21 August 2007 16:04
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"
>
> Sean,
>
> Here I disagree. I believe it is a matter of design and intention, not
> theoretical possibility. Only a very tiny percentage of Java
> applications use JNI to call directly to the underlying system. And in
> those cases, they almost never do so for generating user interfaces.
> That fact that it is a possibility doesn't remove the burden from the
> Java platform from providing the accessibility support that we believe
> is the responsibility of platforms to provide. A key "value
> proposition" of the Java platform is that you can write an application
> that runs on Windows & Macintosh & Solaris & Linux & ..., without
> modification or even recompilation. The only way to deliver that value
> proposition is if the platform provides everything necessary for
> isolation (not whether any particular application uses that isolation).
>
> This is distinct from what any application written for the Java platform
> does or does not do. As you note, because it is possible to use JNI to
> make native calls to the underlying platform, it is possible for Java
> application to bind itself to the Macintosh directly (or to Solaris, or
> Windows), and to use underlying platform calls to generate a user
> interface, etc. Such an application could even make Cocoa accessibility
> API calls (or AT-SPI, or UI Automation, or ...); doing so would be a way
> for that application to meet our draft 508 requirements.
>
> But what we are (I think) trying to do is ensure that such an
> application can meet the 508 requirements *without* needing to resort to
> such underlying-platform-specific means; that instead it can rely on the
> immediately platform - the "middle platform" if you will. It can only
> do that if that middle platform is following a set of rules, and
> providing the necessary accessibility infrastructure/support.
>
>
> The key challenge for us in writing this language, I believe, is to
> capture platforms that are attempting to be platforms and that are
> attempting to provide a rich suite of services that allow for isolation
> from the underlying platform; and leave out software services layers
> that aren't attempting to be such platforms, that aren't attempting to
> allow for such a level of isolation.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> P.S. to carry forward your analogy: being isolated is like being
> pregnant; having the potential to offer isolation is like having a
> functioning womb. We are putting requirements on wombs so that
> gestating babies can make use of an accessible womb without having to
> come out into the larger world to do so.
>
>
>> Peter,
>>
>> I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform
>>
>> Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.
>>
>> If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.
>>
>> We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.
>>
>> If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.
>>
>> Thanks,
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>>
>>

From: Peter Korn
Date: Tue, Aug 21 2007 4:50 PM
Subject: Re: Concerns about our current definition of a "platform"

Sean,

OK, looking at your draft language, you write:

> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>
> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.

But if my platform is a "fully isolating platform", then applications running on my platform *cannot* have access to the underlying platforms accessibility services information. They rather have access to *my* platform's accessibility services information, and it is my platform's responsibility to play translator.

This is part of why I think your 3-W(a) is the wrong approach; we should focus on what a platform that is "intended to create substantially complete environments" *must* provide. If it isn't provided, then apps above it are hosed. There is nothing they can do to be accessible. We have essentially said "you can't meet the technical provisions if you run on X". Now, that is a fine reality, but it should be clear from the get go, and agencies should understand that what they are acquiring is an inaccessible platform, upon which applications cannot be compatible with underlying AT (essentially they have acquiring a closed platform that runs on a potentially open OS), and so all apps on that platform must behave as if they are on a closed system, and be completely self-accessible.

On the other hand, if the platform supports an equivalent of JNI, allowing direct access to the underlying platform/OS, then it should be clear that the route for apps to take to be compatible with AT is via that mechanism, and only that mechanism.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> The difference is the 'intended' part I used is in a should, rather than a shall phrase. If we put it in the definition it becomes a shall again.
>
> I'm not sure why you think I presume they shall have direct access, I created the or, so direct access is only an option if the platform is not interveneing. Perhaps you could elaborate what you mean?
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: 21 August 2007 21:42
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"
>
> Hi Sean,
>
> We are getting closer I think, but not there yet.
>
> Your 3-W(a)(1) and (2) essentially presume apps shall have direct access
> to the underlying platform. That is not a good assumption. I like your
> language "platforms that are intended to create substantially complete
> environments... should provide this functionality within the platform".
> Then, platforms that don't do this must allow applications running on
> them to take the route described in 3-W(a)(1) and (2).
>
> How about a different tack - bring in your phrase "intended to create
> substantially complete environments" into the platform definition?
>
> You said "you can't put an intention into a ruling", but that is
> essentially what you did in your language. Why not use it in the
> definition?
>
>
> Regards,
>
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> But the problem is you can't put an intention into a ruling.
>>
>> I agree that for the most part authors do not use JNI, or equivalents all the time; but it is possible, and that API is there for a reason. Thus applications written for the full Java runtime are (potentially) exposed to two layers of software services. The issue is to create language that would encourage on the one hand that a relatively complete runtime like Java provide the services, but which would not require other less complete software services to provide them when they can adequately rely on the underlying platform services.
>>
>> If we allow your weaker form of definition of platform, perhaps we can modify 3W into two provisions, to be a little more flexible as follows
>>
>>
>> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>>
>> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
>> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.
>>
>> Software that is both a 'platform', and an 'application' running on another platform must either provide this access within the platform itself, or allow applications direct access to the underlying platform. Platforms that are intended to create substantially complete environments, but which also allow access to the underlying platform in a controlled manner, should provide this functionality within the platform.
>>
>> 3 W (b) Software that is both a 'platform', and an 'application' running on another platform must provide mechanisms for moving the keyboard focus into and out of an application, and addressing central conflicts between keyboard mnemonics in the application and the host platform.
>>
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
>> Sent: 21 August 2007 16:04
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"
>>
>> Sean,
>>
>> Here I disagree. I believe it is a matter of design and intention, not
>> theoretical possibility. Only a very tiny percentage of Java
>> applications use JNI to call directly to the underlying system. And in
>> those cases, they almost never do so for generating user interfaces.
>> That fact that it is a possibility doesn't remove the burden from the
>> Java platform from providing the accessibility support that we believe
>> is the responsibility of platforms to provide. A key "value
>> proposition" of the Java platform is that you can write an application
>> that runs on Windows & Macintosh & Solaris & Linux & ..., without
>> modification or even recompilation. The only way to deliver that value
>> proposition is if the platform provides everything necessary for
>> isolation (not whether any particular application uses that isolation).
>>
>> This is distinct from what any application written for the Java platform
>> does or does not do. As you note, because it is possible to use JNI to
>> make native calls to the underlying platform, it is possible for Java
>> application to bind itself to the Macintosh directly (or to Solaris, or
>> Windows), and to use underlying platform calls to generate a user
>> interface, etc. Such an application could even make Cocoa accessibility
>> API calls (or AT-SPI, or UI Automation, or ...); doing so would be a way
>> for that application to meet our draft 508 requirements.
>>
>> But what we are (I think) trying to do is ensure that such an
>> application can meet the 508 requirements *without* needing to resort to
>> such underlying-platform-specific means; that instead it can rely on the
>> immediately platform - the "middle platform" if you will. It can only
>> do that if that middle platform is following a set of rules, and
>> providing the necessary accessibility infrastructure/support.
>>
>>
>> The key challenge for us in writing this language, I believe, is to
>> capture platforms that are attempting to be platforms and that are
>> attempting to provide a rich suite of services that allow for isolation
>> from the underlying platform; and leave out software services layers
>> that aren't attempting to be such platforms, that aren't attempting to
>> allow for such a level of isolation.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>> P.S. to carry forward your analogy: being isolated is like being
>> pregnant; having the potential to offer isolation is like having a
>> functioning womb. We are putting requirements on wombs so that
>> gestating babies can make use of an accessible womb without having to
>> come out into the larger world to do so.
>>
>>
>>
>>> Peter,
>>>
>>> I think the difference here is in the mode of deployment. When Java is being used as an Applet runtime for random internet code, JNI is not available as I understand it. In that mode it is acting as a platform (Note 3); whereas in the case where the applet is signed code that is user installed and JNI is available, Java is essentially being used as a programming language like C++ (albeit with a somewhat stronger discipline). It is still able to access the entire system, and in this mode Java is not acting as a platform
>>>
>>> Isolation (like pregnancy) is a binary condition, you either are, or you are not. Non isolated systems can make it arbitrarily hard to get at the underlying features, but this doesn't make them isolating.
>>>
>>> If Swing provides access to the underlying requirements within the platform (i.e. its available to unsigned applets), then great, that is exactly what we are trying to promote. The applet is isolated, but responds to its platform in an appropriate manner.
>>>
>>> We are using the term platform here in a very narrow sense, and although in common parlance one might say many things are 'platforms', including for example C++. This definition is intentionally stricter. If there is confusion, perhaps we need to use different terms e.g. isolating runtime (platform) and non isolating runtime.
>>>
>>> If there is direct access to the underlying system, then while superficially a system might appear to be a platform, it is in fact just a non isolating runtime, in which case applications written on top of it can be made compliant by directly accessing the features they need. It is important that we retain this distinction, otherwise every runtime library will have to provide these features.
>>>
>>> Thanks,
>>>
>>> Sean Hayes
>>> Incubation Lab
>>> Accessibility Business Unit
>>> Microsoft
>>>
>>>
>>>

From: Sean Hayes
Date: Wed, Aug 22 2007 3:55 AM
Subject: Re: Concerns about our current definition of a "platform"

Here is how I see it:

1 If a platform is completely isolating, then it must provide access within the platform.
2 If not then there is a choice:
a it provides access within the platform (preferred for "substantially complete platforms")
b it provides access to the underlying platform.

In no case is an app running on the platform 'hosed', as they can always get at the required information, although it is perhaps easier if the platform chooses 2a, rather than 2b.

So a platform that is "intended to create substantially complete environments" *must* provide access - they just have a choice *how*.
If you don't think my proposed wording says this, then there is a problem; but that's what I had in mind. I did not intend for any platform to have an 'out' which leaves it inaccessible.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 21 August 2007 23:45
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"

Sean,

OK, looking at your draft language, you write:

> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>
> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.

But if my platform is a "fully isolating platform", then applications running on my platform *cannot* have access to the underlying platforms accessibility services information. They rather have access to *my* platform's accessibility services information, and it is my platform's responsibility to play translator.

This is part of why I think your 3-W(a) is the wrong approach; we should focus on what a platform that is "intended to create substantially complete environments" *must* provide. If it isn't provided, then apps above it are hosed. There is nothing they can do to be accessible. We have essentially said "you can't meet the technical provisions if you run on X". Now, that is a fine reality, but it should be clear from the get go, and agencies should understand that what they are acquiring is an inaccessible platform, upon which applications cannot be compatible with underlying AT (essentially they have acquiring a closed platform that runs on a potentially open OS), and so all apps on that platform must behave as if they are on a closed system, and be completely self-accessible.

On the other hand, if the platform supports an equivalent of JNI, allowing direct access to the underlying platform/OS, then it should be clear that the route for apps to take to be compatible with AT is via that mechanism, and only that mechanism.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Peter Korn
Date: Wed, Aug 22 2007 9:35 AM
Subject: Re: Concerns about our current definition of a "platform"

Hi Sean,

Great, I think we are nearly in complete alignment on this. As you
suggested, I was not reading your wording as doing what you outline
below in 1..2b.

My preference is still that "substantially complete platforms" be at
least strongly encouraged to provide access within the platform. As you
point out, this is where the trickiest language lies. For me, I don't
view it as a lack of completeness if a platform allows an out. Rather,
I view it as a lack of completeness if significant things are impossible
without using that out. And of course, for our purposes, that'd be
significant things relating to the user interface (vs., say, being able
to go into promiscuous mode on a network connection to retrieve all of
the traffic there - something you can't do from within the Java platform
by design & intention).


What I want to avoid is a platform that is designed (and marketed
and...) to be a complete environment where the overwhelming majority of
applications never leave it (e.g. Java, Flash, etc.) - and especially
where they don't leave it for human-computer interaction - should not
then claim it is only "substantially complete" by the very virtue of not
supporting accessibility directly, and thereby saying that their access
solution is to go outside of the platform to the underlying layer to do
what needs to be done.


I guess the ball is in my court now to make another proposal for draft
text... (unless of course Allen wants to give it a go!).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Here is how I see it:
>
> 1 If a platform is completely isolating, then it must provide access within the platform.
> 2 If not then there is a choice:
> a it provides access within the platform (preferred for "substantially complete platforms")
> b it provides access to the underlying platform.
>
> In no case is an app running on the platform 'hosed', as they can always get at the required information, although it is perhaps easier if the platform chooses 2a, rather than 2b.
>
> So a platform that is "intended to create substantially complete environments" *must* provide access - they just have a choice *how*.
> If you don't think my proposed wording says this, then there is a problem; but that's what I had in mind. I did not intend for any platform to have an 'out' which leaves it inaccessible.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
> Sent: 21 August 2007 23:45
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current definition of a "platform"
>
> Sean,
>
> OK, looking at your draft language, you write:
>
>
>> 3-W (a) Applications running on a platform that is also an 'application' running on another platform must have access to:
>>
>> 1 the underlying platform's color, contrast, and other individual display settings, so that these applications can meet the User Preferences provision.
>> 2 the underlying platform's accessibility services information, so that those applications can meet the AT Interoperability provision.
>>
>
> But if my platform is a "fully isolating platform", then applications running on my platform *cannot* have access to the underlying platforms accessibility services information. They rather have access to *my* platform's accessibility services information, and it is my platform's responsibility to play translator.
>
> This is part of why I think your 3-W(a) is the wrong approach; we should focus on what a platform that is "intended to create substantially complete environments" *must* provide. If it isn't provided, then apps above it are hosed. There is nothing they can do to be accessible. We have essentially said "you can't meet the technical provisions if you run on X". Now, that is a fine reality, but it should be clear from the get go, and agencies should understand that what they are acquiring is an inaccessible platform, upon which applications cannot be compatible with underlying AT (essentially they have acquiring a closed platform that runs on a potentially open OS), and so all apps on that platform must behave as if they are on a closed system, and be completely self-accessible.
>
> On the other hand, if the platform supports an equivalent of JNI, allowing direct access to the underlying platform/OS, then it should be clear that the route for apps to take to be compatible with AT is via that mechanism, and only that mechanism.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>

From: Gregg Vanderheiden
Date: Sun, Aug 26 2007 10:40 PM
Subject: Re: Concerns about our current definition of a"platform"

You are indeed correct. I did edit the wrong one.





Here are edits applied on your latest.


*Platform software*:
collection of software components that runs on an underlying
software or
hardware layer, and that provides a set of software services to
applications which allows them to be isolated from the underlying
software or hardware layer.

* Note 1: For our purposes, it is those software
components/services
provided to applications for the creation or
manipulation of user
interfaces and user input - that impact accessibility -
which are
of concern for whether something is a platform or not. An
application offering a compute service, such as a 3d rendering
engine where a requesting application isn't using the software
components/services to create a user interface and interact with
the user, should not be considered a "platform".
* Note 2: If applications typically connect directly to the
underlying layer, rather than relying solely on the platform
software components and services, then it is likely that the
software components in the middle are not acting as a
"platform".
For example, a program which hosts plug-in's is not a
platform if
the plug-in can directly access the underlying layer.
* Note 3: A particular software component may play the role of a
platform in some situations and not in others. Platforms can
include such things as Internet browsers, operating systems,
plug-ins to internet browsers or other software
applications, and
under some situations, byte-code interpreted virtual
environments,
and other "programming within another programming" environments.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Monday, August 20, 2007 9:55 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current
> definition of a"platform"
>
> Gregg,
>
> You provided edits to the version in the 17Aug draft, not to
> the proposal I put forth. Was that your intention? The key
> for me is what the platform provides that defines it as a
> platform (with what the bulk of applications use cementing
> that definition or countering it). With such a definition,
> we can then place requirements on anything that is a platform
> (by that definition).
>
> Going into "partially", and "acting as", and "for those
> aspects of an application" complicates matters significantly.
> And I don't see what we gain by doing that. If something is
> trying to be a platform, then it should obey the platform rules.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

From: Peter Korn
Date: Wed, Aug 29 2007 9:35 AM
Subject: Re: Concerns about our current definition of a"platform"

Gregg,

I did a character comparison between your text below, and my original
from August 20th (see it in the archives - it is the second "Platform
software" definition in:
http://teitac.org/mailarchives/mail_message.php?id=6471&listid=3). The
only difference I found were in space characters and where the line
breaks were.

Did you have any edits to this text that you wanted to discuss/propose?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> You are indeed correct. I did edit the wrong one.
>
>
>
>
>
> Here are edits applied on your latest.
>
>
> *Platform software*:
> collection of software components that runs on an underlying
> software or
> hardware layer, and that provides a set of software services to
> applications which allows them to be isolated from the underlying
> software or hardware layer.
>
> * Note 1: For our purposes, it is those software
> components/services
> provided to applications for the creation or
> manipulation of user
> interfaces and user input - that impact accessibility -
> which are
> of concern for whether something is a platform or not. An
> application offering a compute service, such as a 3d rendering
> engine where a requesting application isn't using the software
> components/services to create a user interface and interact with
> the user, should not be considered a "platform".
> * Note 2: If applications typically connect directly to the
> underlying layer, rather than relying solely on the platform
> software components and services, then it is likely that the
> software components in the middle are not acting as a
> "platform".
> For example, a program which hosts plug-in's is not a
> platform if
> the plug-in can directly access the underlying layer.
> * Note 3: A particular software component may play the role of a
> platform in some situations and not in others. Platforms can
> include such things as Internet browsers, operating systems,
> plug-ins to internet browsers or other software
> applications, and
> under some situations, byte-code interpreted virtual
> environments,
> and other "programming within another programming" environments.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Peter Korn
>> Sent: Monday, August 20, 2007 9:55 PM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Concerns about our current
>> definition of a"platform"
>>
>> Gregg,
>>
>> You provided edits to the version in the 17Aug draft, not to
>> the proposal I put forth. Was that your intention? The key
>> for me is what the platform provides that defines it as a
>> platform (with what the bulk of applications use cementing
>> that definition or countering it). With such a definition,
>> we can then place requirements on anything that is a platform
>> (by that definition).
>>
>> Going into "partially", and "acting as", and "for those
>> aspects of an application" complicates matters significantly.
>> And I don't see what we gain by doing that. If something is
>> trying to be a platform, then it should obey the platform rules.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>
>
>

From: Gregg Vanderheiden
Date: Wed, Aug 29 2007 1:45 PM
Subject: Re: Concerns about our current definition of a"platform"

Sorry
I was just saying that I edited the wrong one. But I didn't have a chance to
re-edit the right one.

Just put " partially or fully " in the provision


> > collection of software components that runs on an underlying
> > software or hardware layer, and that provides a set of software
> > services to applications which allows them to be PARITALLY OR FULLY
isolated from the
> > underlying software or hardware layer.

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Wednesday, August 29, 2007 10:29 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current
> definition of a"platform"
>
> Gregg,
>
> I did a character comparison between your text below, and my
> original from August 20th (see it in the archives - it is the
> second "Platform software" definition in:
> http://teitac.org/mailarchives/mail_message.php?id=6471&listid
> =3). The only difference I found were in space characters
> and where the line breaks were.
>
> Did you have any edits to this text that you wanted to
> discuss/propose?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > You are indeed correct. I did edit the wrong one.
> >
> >
> >
> >
> >
> > Here are edits applied on your latest.
> >
> >
> > *Platform software*:
> > collection of software components that runs on an underlying
> > software or hardware layer, and that provides a set of software
> > services to applications which allows them to be isolated from the
> > underlying software or hardware layer.
> >
> > * Note 1: For our purposes, it is those software
> > components/services
> > provided to applications for the creation or
> manipulation of
> > user
> > interfaces and user input - that impact
> accessibility - which
> > are
> > of concern for whether something is a platform or not. An
> > application offering a compute service, such as a 3d
> rendering
> > engine where a requesting application isn't using
> the software
> > components/services to create a user interface and
> interact with
> > the user, should not be considered a "platform".
> > * Note 2: If applications typically connect directly to the
> > underlying layer, rather than relying solely on the platform
> > software components and services, then it is likely that the
> > software components in the middle are not acting as a
> > "platform".
> > For example, a program which hosts plug-in's is not
> a platform
> > if
> > the plug-in can directly access the underlying layer.
> > * Note 3: A particular software component may play the
> role of a
> > platform in some situations and not in others. Platforms can
> > include such things as Internet browsers, operating systems,
> > plug-ins to internet browsers or other software
> applications,
> > and
> > under some situations, byte-code interpreted virtual
> > environments,
> > and other "programming within another programming"
> environments.
> >
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >> Peter Korn
> >> Sent: Monday, August 20, 2007 9:55 PM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] Concerns about our current
> >> definition of a"platform"
> >>
> >> Gregg,
> >>
> >> You provided edits to the version in the 17Aug draft, not to the
> >> proposal I put forth. Was that your intention? The key for me is
> >> what the platform provides that defines it as a platform
> (with what
> >> the bulk of applications use cementing that definition or
> countering
> >> it). With such a definition, we can then place requirements on
> >> anything that is a platform (by that definition).
> >>
> >> Going into "partially", and "acting as", and "for those
> aspects of an
> >> application" complicates matters significantly.
> >> And I don't see what we gain by doing that. If something
> is trying
> >> to be a platform, then it should obey the platform rules.
> >>
> >>
> >> Regards,
> >>
> >> Peter Korn
> >> Accessibility Architect,
> >> Sun Microsystems, Inc.
> >>
> >>
> >
> >
> >

From: Peter Korn
Date: Wed, Aug 29 2007 2:40 PM
Subject: Re: Concerns about our current definition of a"platform"

Hi Gregg,

I understand what you are saying. I do not agree with it. A provided
set of services that can only partially isolate things above it cannot
ever be a platform. That is distinct from a set of services that are
sufficient for full isolation but which also include an escape hatch.

E.g. if my set of software services provides a way to display windows
but not text (you need to put your own pixels there), then I haven't
provided everything needed and I'm not really a platform. I'm just a
software library - and an incomplete one at that. To take your
definition, we would then be placing a burden on virtually any software
toolkit or software library. Heck, the standard C library containing
disk and network i/o functions "partially isolates" you from the
"underlying hardware layer" (namely the disk & network firmware). But
that isn't a platform.

I recognize that sometimes a platform like a browser is a platform for
HTML, but only a set of software services for a browser plugin like
Flash or Java applets. But here the word "partially" isn't helpful. It
is a platform to some things, and a library to others.


Perhaps we might move this discussion forward if you could give concrete
examples of things you feel are platforms that aren't covered by
language that doesn't include "partially".


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Sorry
> I was just saying that I edited the wrong one. But I didn't have a chance to
> re-edit the right one.
>
> Just put " partially or fully " in the provision
>
>
>
>>> collection of software components that runs on an underlying
>>> software or hardware layer, and that provides a set of software
>>> services to applications which allows them to be PARITALLY OR FULLY
>>>
> isolated from the
>
>>> underlying software or hardware layer.
>>>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Peter Korn
>> Sent: Wednesday, August 29, 2007 10:29 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Concerns about our current
>> definition of a"platform"
>>
>> Gregg,
>>
>> I did a character comparison between your text below, and my
>> original from August 20th (see it in the archives - it is the
>> second "Platform software" definition in:
>> http://teitac.org/mailarchives/mail_message.php?id=6471&listid
>> =3). The only difference I found were in space characters
>> and where the line breaks were.
>>
>> Did you have any edits to this text that you wanted to
>> discuss/propose?
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>> You are indeed correct. I did edit the wrong one.
>>>
>>>
>>>
>>>
>>>
>>> Here are edits applied on your latest.
>>>
>>>
>>> *Platform software*:
>>> collection of software components that runs on an underlying
>>> software or hardware layer, and that provides a set of software
>>> services to applications which allows them to be isolated from the
>>> underlying software or hardware layer.
>>>
>>> * Note 1: For our purposes, it is those software
>>> components/services
>>> provided to applications for the creation or
>>>
>> manipulation of
>>
>>> user
>>> interfaces and user input - that impact
>>>
>> accessibility - which
>>
>>> are
>>> of concern for whether something is a platform or not. An
>>> application offering a compute service, such as a 3d
>>>
>> rendering
>>
>>> engine where a requesting application isn't using
>>>
>> the software
>>
>>> components/services to create a user interface and
>>>
>> interact with
>>
>>> the user, should not be considered a "platform".
>>> * Note 2: If applications typically connect directly to the
>>> underlying layer, rather than relying solely on the platform
>>> software components and services, then it is likely that the
>>> software components in the middle are not acting as a
>>> "platform".
>>> For example, a program which hosts plug-in's is not
>>>
>> a platform
>>
>>> if
>>> the plug-in can directly access the underlying layer.
>>> * Note 3: A particular software component may play the
>>>
>> role of a
>>
>>> platform in some situations and not in others. Platforms can
>>> include such things as Internet browsers, operating systems,
>>> plug-ins to internet browsers or other software
>>>
>> applications,
>>
>>> and
>>> under some situations, byte-code interpreted virtual
>>> environments,
>>> and other "programming within another programming"
>>>
>> environments.
>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>>>> Peter Korn
>>>> Sent: Monday, August 20, 2007 9:55 PM
>>>> To: TEITAC Web/Software Subcommittee
>>>> Subject: Re: [teitac-websoftware] Concerns about our current
>>>> definition of a"platform"
>>>>
>>>> Gregg,
>>>>
>>>> You provided edits to the version in the 17Aug draft, not to the
>>>> proposal I put forth. Was that your intention? The key for me is
>>>> what the platform provides that defines it as a platform
>>>>
>> (with what
>>
>>>> the bulk of applications use cementing that definition or
>>>>
>> countering
>>
>>>> it). With such a definition, we can then place requirements on
>>>> anything that is a platform (by that definition).
>>>>
>>>> Going into "partially", and "acting as", and "for those
>>>>
>> aspects of an
>>
>>>> application" complicates matters significantly.
>>>> And I don't see what we gain by doing that. If something
>>>>
>> is trying
>>
>>>> to be a platform, then it should obey the platform rules.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Peter Korn
>>>> Accessibility Architect,
>>>> Sun Microsystems, Inc.
>>>>
>>>>
>>>>
>>>

From: Gregg Vanderheiden
Date: Wed, Aug 29 2007 11:35 PM
Subject: Re: Concerns about our current definition of a"platform"

Sorry Peter,

I didn't say it WAS a platform. Just that it was providing some platform
services or serving as a platform. (see your Note 3).


Personally I think labeling things as platform or application is the wrong
approach. I think we should say

Software serving as a platform (or providing platform services to other
software) should.....

And

Software with user interface should....


Or some such.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Wednesday, August 29, 2007 3:03 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Concerns about our current
> definition of a"platform"
>
> Hi Gregg,
>
> I understand what you are saying. I do not agree with it. A
> provided set of services that can only partially isolate
> things above it cannot ever be a platform. That is distinct
> from a set of services that are sufficient for full isolation
> but which also include an escape hatch.
>
> E.g. if my set of software services provides a way to display
> windows but not text (you need to put your own pixels there),
> then I haven't provided everything needed and I'm not really
> a platform. I'm just a software library - and an incomplete
> one at that. To take your definition, we would then be
> placing a burden on virtually any software toolkit or
> software library. Heck, the standard C library containing
> disk and network i/o functions "partially isolates" you from
> the "underlying hardware layer" (namely the disk & network
> firmware). But that isn't a platform.
>
> I recognize that sometimes a platform like a browser is a
> platform for HTML, but only a set of software services for a
> browser plugin like Flash or Java applets. But here the word
> "partially" isn't helpful. It is a platform to some things,
> and a library to others.
>
>
> Perhaps we might move this discussion forward if you could
> give concrete examples of things you feel are platforms that
> aren't covered by language that doesn't include "partially".
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Sorry
> > I was just saying that I edited the wrong one. But I didn't have a
> > chance to re-edit the right one.
> >
> > Just put " partially or fully " in the provision
> >
> >
> >
> >>> collection of software components that runs on an underlying
> >>> software or hardware layer, and that provides a set of software
> >>> services to applications which allows them to be
> PARITALLY OR FULLY
> >>>
> > isolated from the
> >
> >>> underlying software or hardware layer.
> >>>
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >> Peter Korn
> >> Sent: Wednesday, August 29, 2007 10:29 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] Concerns about our current
> >> definition of a"platform"
> >>
> >> Gregg,
> >>
> >> I did a character comparison between your text below, and
> my original
> >> from August 20th (see it in the archives - it is the
> second "Platform
> >> software" definition in:
> >> http://teitac.org/mailarchives/mail_message.php?id=6471&listid
> >> =3). The only difference I found were in space characters
> and where
> >> the line breaks were.
> >>
> >> Did you have any edits to this text that you wanted to
> >> discuss/propose?
> >>
> >>
> >> Regards,
> >>
> >> Peter Korn
> >> Accessibility Architect,
> >> Sun Microsystems, Inc.
> >>
> >>
> >>> You are indeed correct. I did edit the wrong one.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Here are edits applied on your latest.
> >>>
> >>>
> >>> *Platform software*:
> >>> collection of software components that runs on an underlying
> >>> software or hardware layer, and that provides a set of software
> >>> services to applications which allows them to be
> isolated from the
> >>> underlying software or hardware layer.
> >>>
> >>> * Note 1: For our purposes, it is those software
> >>> components/services
> >>> provided to applications for the creation or
> >>>
> >> manipulation of
> >>
> >>> user
> >>> interfaces and user input - that impact
> >>>
> >> accessibility - which
> >>
> >>> are
> >>> of concern for whether something is a platform or not. An
> >>> application offering a compute service, such as a 3d
> >>>
> >> rendering
> >>
> >>> engine where a requesting application isn't using
> >>>
> >> the software
> >>
> >>> components/services to create a user interface and
> >>>
> >> interact with
> >>
> >>> the user, should not be considered a "platform".
> >>> * Note 2: If applications typically connect directly to the
> >>> underlying layer, rather than relying solely on
> the platform
> >>> software components and services, then it is
> likely that the
> >>> software components in the middle are not acting as a
> >>> "platform".
> >>> For example, a program which hosts plug-in's is not
> >>>
> >> a platform
> >>
> >>> if
> >>> the plug-in can directly access the underlying layer.
> >>> * Note 3: A particular software component may play the
> >>>
> >> role of a
> >>
> >>> platform in some situations and not in others.
> Platforms can
> >>> include such things as Internet browsers,
> operating systems,
> >>> plug-ins to internet browsers or other software
> >>>
> >> applications,
> >>
> >>> and
> >>> under some situations, byte-code interpreted virtual
> >>> environments,
> >>> and other "programming within another programming"
> >>>
> >> environments.
> >>
> >>>
> >>> Gregg
> >>> -- ------------------------------
> >>> Gregg C Vanderheiden Ph.D.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: = EMAIL ADDRESS REMOVED =
> >>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >>>> Peter Korn
> >>>> Sent: Monday, August 20, 2007 9:55 PM
> >>>> To: TEITAC Web/Software Subcommittee
> >>>> Subject: Re: [teitac-websoftware] Concerns about our current
> >>>> definition of a"platform"
> >>>>
> >>>> Gregg,
> >>>>
> >>>> You provided edits to the version in the 17Aug draft, not to the
> >>>> proposal I put forth. Was that your intention? The key
> for me is
> >>>> what the platform provides that defines it as a platform
> >>>>
> >> (with what
> >>
> >>>> the bulk of applications use cementing that definition or
> >>>>
> >> countering
> >>
> >>>> it). With such a definition, we can then place requirements on
> >>>> anything that is a platform (by that definition).
> >>>>
> >>>> Going into "partially", and "acting as", and "for those
> >>>>
> >> aspects of an
> >>
> >>>> application" complicates matters significantly.
> >>>> And I don't see what we gain by doing that. If something
> >>>>
> >> is trying
> >>
> >>>> to be a platform, then it should obey the platform rules.
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Peter Korn
> >>>> Accessibility Architect,
> >>>> Sun Microsystems, Inc.
> >>>>
> >>>>
> >>>>
> >>>