Title: Message
I think
I see your point (I thought of modification as semantic versus syntactic), how
about the following wording (which still puts the Customization issue
aside):
This specification must support common Presentation formats, which are in use today in Net-enabled
applications. In particular:
1.
It MUST support
Presentation Fragments in HTML, XHTML, XML and
WML.
2. It MUST
support JavaScript as an associated scripting language. Such support MUST include a way to support Actions triggered by scripts.
However, it SHOULD NOT be assumed that the Consumer
is aware of the semantics of scripting
elements.
3.
It SHOULD support
embedded binary presentation elements (e.g., Flash, Applets, etc.).
[Optional/Debate: Such
support SHOULD provide a way
to support Actions triggered by such
elements.]
However, it SHOULD NOT be
assumed that the Consumer modifies the binary elements in any way.
I personally
think it makes sense to favor a single technical approach that captures both (2)
and (3), but I also don't see it as a high-level requirement but rather as a
technical preference.
-----Original Message-----
From: Sean Fitts
[mailto:]
Sent: Wednesday, May 08, 2002 2:14
PM
To: Eilon Reshef; 'Rich Thompson';
Subject: RE:
[wsia][wsia-requirements][R602]
At 01:55 PM 5/8/2002
-0400, Eilon Reshef wrote:
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).
I don't
see a connection between supporting modification of JavaScript
(which I
agree is an open issue) and the need to support complete,
path wise
analysis of it. Leaving the halting problem aside for a bit, it
would
seem possible to extend the Adaptation Description Language
proposed by IBM
to include JavaScript modifications along with XML
and CSS ones.
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?
Again, I don't see how leaving
the second sentence out leads to
*requiring* the Consume to analyze or even
modify JavaScript. Such a
statement would seem to need a positive
assertion that such modification
*is* a requirement (something which
again, I view as open).
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.
I guess my take is that it is too
generic. It seems to be trying to
take a half step and would result
in muddying things instead of making
them clearer. If it really
doesn't place any restrictions one way or the
other on our work, then it
doesn't seem like a requirement and I would
argue it should not be
included.
Sean
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.
