At 12:00 PM 5/8/2002 -0400, Eilon Reshef wrote:
Composing
the above discussion, how about the summary below (I tried to incorporate
the debates below):
This specification must support common
Presentation Formats, which are in use today in Net-enabled applications.
In particular:
1. It MUST support HTML and XHTML as Presentation Formats.
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.
3. It MUST NOT preclude the use of embedded
binary presentation formats (e.g., Flash, GIFs, etc.).
[Optional/Debate: and MUST provide a way to support actions triggered by
such elements].
However, it MUST NOT be assumed that binary presentation in is modified
by the Consumer in any way.
I would argue that supporting actions in binary formats should
*not*
be part of the first release. However, this is more of a
non-requirement
than a requirement.
Sean
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Wednesday, May 08, 2002 11:33 AM
To:
Subject: RE: [wsia][wsia-requirements][R602]
I agree that the prevalence of JavaScript will require that we
address it
even in the first release.
As to the meaning of "should not", RFC 2119 says:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before
implementing any behavior described with this label.
I take this to mean in this context that the committee will not eliminate
the possibility of carrying other formats (such as flash) without having
good reasons after careful considerations of the issues and implications.
In contrast, using "must not" is an absolute constraint ... I'm just
concerned that we not place that constraint on ourselves without
understanding the implications.
Eilon Reshef
<eilon.reshef@webc To: Ravi Konuru/Watson/IBM@IBMUS,
ollage.com> cc:
Subject: RE: [wsia][wsia-requirements][R602]
05/08/2002 10:57
AM
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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
