Title: Message
Is your intention VBScript? (The statement refers to client-side
languages)
-----Original Message-----
From: Young, Brian R
[mailto:]
Sent: Wednesday, May 08, 2002
5:53 PM
To: 'Eilon Reshef'; 'Sean Fitts';
Subject: RE:
[wsia][wsia-requirements][R602]
What
about support for scripting languages other than
JavaScript?
Brian R.
Young
The
Boeing Company
(425) 865-5834
DISCLAIMER: Any opinions
expressed in this e-mail are my own and do not necessarily reflect the
position of my company.
-----Original Message-----
From: Eilon Reshef
[mailto:]
Sent: Wednesday, May 08,
2002 1:51 PM
To: 'Sean Fitts';
Subject: RE:
[wsia][wsia-requirements][R602]
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.
