OASIS Web Services Interactive Applications TC

 View Only

RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]

  • 1.  RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]

    Posted 05-10-2002 15:16
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    wsia message

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


    Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]


    
    Eilon, this is really nice, thanks for continually trying to rationalize
    this particular requirement. I think it is a particularly important one.
    
    The first three are clear. My opinion is that reqt 4 is not at the same
    granularity as the other three reqmts. I would divide 4 into the following.
    
          4a. It MUST define guidelines on Presentation Fragments in HTML,
    XHTML, XML and WML so that features mentioned elsewhere in the document
    such as  action routing and adaptation can be performed.
          4b. It MUST?SHOULD define guidelines on  ECMAScript scripts so that
    features such as action routing and adaptation are enabled.
          4->4c Functionality offered elsewhere in this specification (e.g.,
    action routing, customization) SHOULD NOT be restricted based on a
    particular presentation format. However, this specification MAY only
    provide constructive guidelines for other restricted set of presentation
    formats
    
    Also, we should think of this extracted response from Kurt Cagle's mail in
    the context of 4c. I think its very relavant. In fact, this was also one of
    the thoughts in IBM's WSXL position paper. We may want to use this line for
    all binary formats. Imagine
    if script writers follow this approach :-) then we are all set. We don't
    have to grok through anything anymore.
    
    On the other front, concerning plug-in technology, I'd recommend just
    taking
    a hint from HTML and create a standardized <object> or <embed> capability
    that includes parameter passing, plug-in source code and viewport
    specification sizes. Couple this with a mechanism to let these plug-ins
    hook
    into a native web service capability for conformity sake, and you don't
    need
    to worry about formal support of a given vendor's products - they would
    instead write a wrapper AI to be conformant with the WSIA spec.
    
    
    
    
    Ravi Konuru
    eBusiness Tools and Frameworks, IBM Research
    office: 914-784-7180, tieline 8-863-7180; fax -3804
    
    
                                                                                                                                
                          Eilon Reshef                                                                                          
                          <eilon.reshef@webc        To:       "'Sean Fitts'" <sean@crossweave.com>, Ravi                        
                          ollage.com>                Konuru/Watson/IBM@IBMUS                                                    
                                                    cc:       wsia@lists.oasis-open.org                                         
                          05/10/2002 01:44          Subject:  RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]                
                          PM                                                                                                    
                                                                                                                                
                                                                                                                                
    
    
    
    Here's another round based on the latest comments, with a clearer
    distinction between what we commit to do versus what we wish to do long
    term (based on Ravi's observation). I also don't think we need to spell out
    the different things that are supported, but I do see an slight conceptual
    distinction between action routing and customization (see below).
    
    
    This specification must support common Presentation formats, which are in
    use today in Net-enabled applications. In particular:
    
    
    1. It MUST support Presentation Fragments in HTML, XHTML, XML and WML.
    
    2. It MUST support Presentation Fragments and Actions created by ECMAScript
    scripts.
    
    [ER]: Presentation Fragments are document.write() and DOM function calls.
    Actions are navigation (non-presentation) function calls (such as
    location.replace).
    
    3. It MUST support embedded elements (e.g., Images, Flash, Applets, etc.)
    (and Actions created by such elements?).
    
    [ER]: Presentation Fragments are things displayed to the user, actions are
    navigation commands. I do think that not allowing supporting actions in
    such formats is limiting.
    
    4. Functionality offered elsewhere in this specification (e.g., action
    routing, customization) SHOULD NOT be restricted based on a particular
    presentation format. However, this specification MAY only provide
    constructive guidelines for a restricted set of presentation formats.