RE: programmatically determined and AT

Hi Christophe, 

   I'm trying to work out the implications here.   Would this have the
effect of making only markup languages conform (declarative) but not script
(imperative)? 

Also, declarative doesn't mean that AT can actually access it - even if it
is static.  

Our problem was that we can't define AT specifically without naming specific
AT (since there is no AT interop standard).   And this doesn't seem to
address that.

It is a very interesting thought though.   Just not sure if it addresses the
key problem. 

Further thoughts? 
 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Christophe Strobbe
Sent: Wednesday, January 25, 2006 11:54 AM
To: w3c-wai-gl@w3.org
Subject: programmatically determined and AT


Hi,

We still don't have a satisfactory solution for "programmatically 
determined" and AT. "Theoretically programmatically determined because 
defined in formal specifications" is not sufficient because there may be 
features in specifications that no AT has implemented yet. On the other 
hand we can't just say "AT" without saying which AT.

What we have not discussed so far is the distinction between
- programmatically determined in a declarative manner, and
- programmatically determined in an imperative manner.

This distinction is based on the distinction between declarative and 
imperative (programming) languages:
- imperative languages basically describe sequences of operations,
- declarative languages basically describe what is computer.[1]

We deleted the old SC 3.2 L1 SC1 ("Any change of context is implemented in 
a manner that can be programmatically determined.") on the basis that any 
change of context that cannot be programmatically determined will simply 
never happen because a UA cannot detect that it is supposed to happen. The 
SC would not have been removed if it had read: "Any change of context is 
implemented in a declarative way". That would have ruled out changes of 
context caused by JavaScript (which is an imperative language), which many 
will find to strong at level 1.

The distinction between declarative and imperative is interesting because 
it is what gave rise to the XML Events spec 
(http://www.w3.org/TR/2003/REC-xml-events-20031014/) and the use of XML 
Events in XForms (http://www.w3.org/TR/2003/REC-xforms-20031014/). Many 
things that HTML form authors do with JavaScript (imperative code) can now 
be done with XML Events (required fields, hints, context-sensitive help, 
adding fields based on the value of other fields, etc). This has the 
advantage that events (and therefore changes of context) are "statically 
analyzable": there's no need for AUs to actually run any code (JavaScript) 
to find out what kinds of events might happen.
Can this be a way out of this catch-22?


[1] More on this subject at 
http://www.csc.liv.ac.uk/~frans/OldLectures/2CS24/declarative.html and 
http://en.wikipedia.org/wiki/Declarative_programming.

Regards,

Christophe Strobbe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Wednesday, 25 January 2006 18:30:14 UTC