Title: Message
My thought was around people that use scripts like
this:
<script>
var target = "http://" + gMyDomain +
"/mypage.rgb?page="
+ document.form[1].pageNumber.value;
document.location = targert;
</script>
My intent was to formulate a part of the requirement that clearly states
that WSIA cannot expect Consumers to automatically rewrite this action to point
back to the Consumer.
Does this make sense as the intent of this part of the
requirement?
As for a proposed solution, one can consider three
options:
1. Disallow such cases and other such constructs (which is always the
last resort).
2. Define a meta-language that does not require changes to the script
(assuming it's a script that was written beforehand), and tries to capture the
replacement locations externally (a-la adaptation). However, the halting problem
(;-) does argue that there will still be cases that the external language won't
be able to address.
3. Ensure that enough information is passed to the Producer so that when
it either writes new applications or when it needs to adapt cases like this, it
would be technically possible.
Any thoughts?
Eilon
-----Original Message-----
From: Sean Fitts
[mailto:]
Sent: Wednesday, May 08, 2002 5:57
PM
To: Eilon Reshef;
Subject:
RE: [wsia][wsia-requirements][R602]
At 04:51 PM 5/8/2002
-0400, Eilon Reshef wrote:
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):
One
small tweak, the modifications may be semantic, but the semantics are
largely implied and will likely need to be described externally (ala the
adaptation
description in WSXL).
I guess I don't see a lot
of difference here between this type of modification and
general markup
modification. Both contain semantic information, both require
some
sort of locator to identify the sections implementing a given semantic
operation, and in both cases, the semantics are opaque.
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.
Given the parallel between semantics of
scripting elements and semantics
of other elements (such as markup and/or
actions), I still don't see the need
for the second statement.
However, in this form it seems a lot more benign
(at least to my
eye).
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.
Could you elaborate on this? I'm
not sure I understand. Thanks.
Sean
-----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.
