[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsia-requirements][R602]
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.]
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.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:33 AM
To: wsia@lists.oasis-open.org
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, wsia@lists.oasis-open.org
- 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: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>
- ----------------------------------------------------------------
- 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