[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsia-requirements][R602]
As I said earlier, We cannot ignore javascript eventhough its binary. Its
too prevalent
We need to define what means to customize java script. Here are some
thoughts.
- routing control (Required)
- interception and interpretation of invocations from java script to
the WSIA service (Required for customized case)
- interception and interpretation of invocations from one javascript
function to another local function
- modifying event handlers
- modifying data and control variables.
- modifying code. (add a new line in a javscript code, IMO
prepostrous but kept for completeness )
To enable each of these, we need to define the architecture and potentially
guidelines on how javascript is generated.
Note that a WSIA service may choose to only provide the first two wrt java
script so may be less customizable than
another WSIA service.
If do define guidelines for the first two items in the list, IMO we should
be able to use the same guidelines for other *binary* formats.
regards,
Ravi.
Sean Fitts
<sean@crossweave. To: Eilon Reshef <eilon.reshef@webcollage.com>, Ravi
com> Konuru/Watson/IBM@IBMUS, wsia@lists.oasis-open.org
cc:
05/08/2002 11:23 Subject: RE: [wsia][wsia-requirements][R602]
AM
I would completely agree that we should avoid customization of
*binary* formats for the first release. However, I agree with Elion
that even if we might like to (and personally I don't), we cannot
treat JavaScript as a binary for this purpose.
Beyond the fact that it *isn't* binary, as Elion points out it is just
used way too much. In fact, the use of JavaScript to dynamically
generate not just validation logic, but entire UI's is increasing in
usage (just take a look at the recent product releases from both
Siebel and PeopleSoft).
IMO, if the WSIA is going to be at all relevant, we have to acknowledge
and allow for the current best practices. If to become WSIA compliant,
companies must completely re-write their existing applications, then
WSIA adoption will be seriously impeded.
To me this means that we must allow for customization of JavaScript
and not just for action routing purposes.
Sean
At 10:57 AM 5/8/2002 -0400, Eilon Reshef wrote:
Ravi,
I think that your observation that JavaScript is essentially "yet
another binary format" catches the bull by its horns - in a way, that
sharpens the question.
It more than makes sense - in my view - to ignore customization of
binary formats for the first release (at least by the Consumer, the
Producer can always hand-code anything).
However, to me, supporting action routing in JavaScript (even if not
transparently) is a must. (There are way too many apps that use
JavaScript for links and forms).
Eilon
-----Original Message-----
From: Ravi Konuru [mailto:rkonuru@us.ibm.com]
Sent: Wednesday, May 08, 2002 9:59 AM
To: wsia@lists.oasis-open.org
Subject: RE: [wsia][wsia-requirements][R602]
Questions/comments:
- Is Java script being considered non- binary in these
discussions?
From my perspective, it is binary.
- Does "Should not" mean that we will "try" not to
introduce in our
specification assumptions about output of a service? This is
not
verifiable. I rather say we will initially focus on XML formats
but will
tackle binary formats in the next rev? However, don't like this
option. see
next.
- Should we define a set of guidelines for downloaded
binary code to
allow at least for routing if not for customization? I prefer
this. Given
the prevalence of downloaded code (script and flash). We should
say what
works and what doesn't.
regards,
Ravi Konuru
Rich
Thompson/Watson/I To:
wsia@lists.oasis-open.org
BM@IBMUS cc:
Subject: RE:
[wsia][wsia-requirements][R602]
05/06/2002 08:39
AM
While I do think we need to think about how a Consumer can
provide enough
information that a Producer could embed action invocations and
the like in
binary formats, I think the last sentence needs to be a SHOULD
NOT rather
than a MUST NOT as it may not turn out to be feasible once we
consider this
for a multi-tiered chain of Producers and Consumer.
Eilon Reshef
<eilon.reshef@webc To:
"'Alan Kropp'"
<akropp@epicentric.com>,
ollage.com>
wsia@lists.oasis-open.org
cc:
05/06/2002 01:06 Subject: RE:
[wsia][wsia-requirements][R602]
AM
I'll put my 1.5 cents into this discussion, even though I
didn't originally
put my name for it :-)
I think that it more than makes sense that we shouldn't ask the
Consumer to
parse and modify Flash content, Java applets, or any other
binary format.
The question in my mind (regarding the actual intent of this
requirement)
is: should the WSIA protocol *permit* some sequence of calls in
which a
WSIA Web Service that contains Flash/Java/ActiveX with links or
forms would
still work, even though it has user interaction, and even
though "smart
look-and-feel customization" (whatever this is) will not be
offered.
This point - although seemingly minor - may have significant
implications
on the actual protocol with regards to action routing.
If we do decide that binary formats should be supported even at
a basic
level, then (at least according to my possibly limited
understanding) this
means that we must provide at least some way (not necessarily
the
"mainstream" way) for the Consumer to provide enough
information to the
Producer (who serves the binary data) so that the binary
content is served
in such a way in which all the actions are routed correctly to
the
Consumer. This means that the Producer has to take care of it,
but it would
make it doable.
We at WebCollage have encountered some cases where people used
Flash for
parts of their applications, so it made sense for us to
consider it.
However, we need to decide whether this is something that the
WSIA
committee as a whole cares about.
Eilon
-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Friday, May 03, 2002 8:41 PM
To: 'wsia@lists.oasis-open.org'
Subject: [wsia][wsia-requirements][R602]
R602 [Flexibility]
This specification should support common
Presentation
Formats, which are in use today in Net-enabled
applications. In
particular,
it should support HTML, XHTML, WML and XML as
Presentation Formats.
It must
not preclude the use of other presentation formats
(Eilon: such as
Flash,
GIFs, etc.). Debate on last sentence: AK, CW.
I think only XML and HTML (due to its ubiquity) markups
should be
supported
by name, other formats should be considered opaque in the
markup
stream.
Last sentence should read:
It must not preclude the use of other presentation
formats, although
these
(e.g., Flash, GIFs, etc.) shall be considered opaque in
the markup
stream.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC