Title: Message
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:]
Sent: Wednesday, May 08, 2002 9:59
AM
To:
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:
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'"
<>,
ollage.com>
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:]
Sent: Friday, May 03, 2002
8:41 PM
To:
''
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>
