[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC