Title: Message
I am not suggesting that the Consumer is not
allowed to change JavaScript, rather the suggestion is that
we wouldn't assume that it should. To me, that's because correctly
analyzing code constructs (in any language) without executing them is anywhere
from hard (from a practical perspective) to impossible (from a theoretical
perspective, as Theory of Computation shows).
This is not to say that WSIA can't define an interface
that uses JavaScript (e.g., I assume the committee may decide to define
JavaScript functions, events, etc.), but I guess that the question is can we
require the Consumer to analyze JavaScript code to support action
routing, for example?
Customization is
definitely something that we will be discussing in the Customization
sub-committee. My working assumption is that the
requirement below is rather generic, and applies to anywhere from the
scope of WSIA in general, to action routing, unique tokens, etc., and that it might be changed as the Customization
sub-committee proceeds.
Eilon
-----Original Message-----
From: Sean
Fitts [mailto:]
2. It MUST
support JavaScript as an associated scripting language and MUST provide a
way to support actions triggered by scripts. [Optional/Debate: However, it
MUST NOT be assumed that scripting elements are modified by the Consumer in
any way.]Why do you feel that the second "MUST NOT"
statement is necessary?
To me it seems overly restrictive since it impacts
both what types of
customization we will support and where the
customization will occur.
My understanding is that both of these issues are
still up for debate/
description in the customization sub-group.
