Thread Subject: Re: Concerns about our current definition of a "platform"
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Peter Korn
Date: Tue, Aug 21 2007 9:10 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Sean Hayes: "Re: Concerns about our current definition of a "platform""
- Previous message in thread: Sean Hayes: "Re: Concerns about our current definition of a "platform""
- Messages sorted by: Author | Thread | Date
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.
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.
> 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.
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
- Next message in Thread: Sean Hayes: "Re: Concerns about our current definition of a "platform""
- Previous message in Thread: Sean Hayes: "Re: Concerns about our current definition of a "platform""