RE: [wsia][wsia-requirements][R602]

[Sean Fitts <sean@crossweave.com>]

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>