OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

As I said earlier, We cannot ignore javascript eventhough its binary. Its
too prevalent

We need to define what means to customize java script. Here are some
      - routing control (Required)
      - interception and interpretation of invocations from java script to
the WSIA service (Required for customized case)
      - interception and interpretation of invocations from one javascript
function to another local function
      - modifying event handlers
      - modifying data and control variables.
      - modifying code. (add a new line in a javscript code, IMO
prepostrous but kept for completeness )

To enable each of these, we need to define the architecture and potentially
guidelines on how javascript is generated.
Note that a WSIA service may choose to only provide the first two wrt java
script so may be less customizable than
another WSIA service.

If do define guidelines for the first two items in the list, IMO we should
be able to use the same guidelines for other *binary* formats.


                      Sean Fitts                                                                                           
                      <sean@crossweave.        To:       Eilon Reshef <eilon.reshef@webcollage.com>, Ravi                  
                      com>                      Konuru/Watson/IBM@IBMUS, wsia@lists.oasis-open.org                         
                      05/08/2002 11:23         Subject:  RE: [wsia][wsia-requirements][R602]                               

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.


At 10:57 AM 5/8/2002 -0400, Eilon Reshef wrote:

      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).

            -----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]

                  - Is Java script being considered non- binary in these
            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
            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
                  - 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.
            Ravi Konuru

                                  Thompson/Watson/I        To:
                                  BM@IBMUS                 cc:
                                                           Subject:  RE:
                                  05/06/2002 08:39

            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'"


                                  05/06/2002 01:06          Subject:  RE:

            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
            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

            This point - although seemingly minor - may have significant
            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
            "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
            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
            committee as a whole cares about.

                  -----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

                  Formats, which are in use today in Net-enabled
            applications. In
                  it should support HTML, XHTML, WML and XML as
            Presentation Formats.
                  It must
                  not preclude the use of other presentation formats
            (Eilon: such as
                  GIFs, etc.). Debate on last sentence: AK, CW.

                  I think only XML and HTML (due to its ubiquity) markups
            should be
                  by name, other formats should be considered opaque in the
                  Last sentence should read:

                   It must not preclude the use of other presentation
            formats, although
                  (e.g., Flash, GIFs, etc.) shall be considered opaque in
            the markup


                  To subscribe or unsubscribe from this elist use the
                  manager: <http://lists.oasis-open.org/ob/adm.pl>


            To subscribe or unsubscribe from this elist use the
            manager: <http://lists.oasis-open.org/ob/adm.pl>


            To subscribe or unsubscribe from this elist use the
            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