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 13:11
     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]


    Complete support sounds like a plan to me, too.
    
    Ciao,
    Rex
    
    
    
    At 9:27 AM -0700 5/10/02, Sean Fitts wrote:
    >Ravi, thanks.  Your description of providing "support" for a format vs.
    >just passing it along (and making sure not to muck it up) is exactly
    >what was lurking in the back of my mind.
    >
    >I guess the thing that confused me was that we explicitly called out
    >Action routing, but failed to mention all the other aspects of providing
    >"support" for a given element.  I wasn't sure if this was intentional or
    >just because the other aspects are handled by other requirements.
    >
    >For instance, if the WSIA supported Action routing from scripts, but
    >did not support adaptation of generated markup, would it meet this
    >requirement?  I don't think it should, but I'm not entirely sure that this
    >is true as currently worded.
    >
    >So, 2 questions - do others agree that we need to provide "complete
    >support" (as outlined by Ravi below) for scripts?  If not, why not?
    >
    >Any thoughts on the current wording and whether it captures this intent?
    >
    >Sean
    >
    >At 09:04 AM 5/10/2002 -0400, Ravi Konuru wrote:
    >
    >>  > Do we want to say anything about additional Presentation Fragments
    >>generated
    >>>  by scripts?
    >>
    >>We MUST support them and I am assuming that by support, we mean action
    >>routing, interpretation, and adaptation. As you pointed there is so much
    >>use of it that we cannot ignore. However, in general wrt javascript do we
    >>explicitly mention that there may be guidelines on javascript coding so
    >>that we can do routing?
    >>
    >>After reading through your version of reqmt 3. It seems we need to
    >>distinguish between delivering a format opaquely/pass-through vs what I
    >>defined above as support. Should we use the words "Carry or Opaquely
    >>transport" and "Support" to distinguish the two or am I missing something?
    >>
    >>regards,
    >>Ravi Konuru
    >>eBusiness Tools and Frameworks, IBM Research
    >>office: 914-784-7180, tieline 8-863-7180; fax -3804
    >>
    >>
    >>
    >>
    >>                       Sean Fitts
    >>                       <sean@crossweave.        To:       Eilon 
    >>Reshef <eilon.reshef@webcollage.com>, "'Monica Martin'"
    >>                       com> 
    >><mmartin@certivo.net>, wsia@lists.oasis-open.org
    >>                                                cc:
    >>                       05/10/2002 03:05         Subject:  RE: WSIA 
    >>5/9/2002: [wsia][wsia-requirements][R602]
    >>                       AM
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>At 10:11 PM 5/9/2002 -0400, Eilon Reshef wrote:
    >>       If I remember correctly, Sean did not feel comfortable with the last
    >>       sentence of statement 2 and the word "binary".
    >>
    >>       So, where we stand might be the following, with the exception that we
    >>       still need to solicit input on the second part of statement 3.
    >>
    >>       Sean - I did no go back to the somewhat long discussion yesterday, so
    >>       please do (continue to ;-) correct me if I missed something...
    >>
    >>No problem, sorry for rambling on, it's really not like me :-).
    >>
    >>
    >>       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.
    >>
    >>Do we want to include cHTML or is that dead at this point?
    >>
    >>
    >>       2. It MUST support ECMAScript as an associated scripting language,
    >>       and MUST include a way to correctly route Actions triggered by
    >>       scripts.
    >>
    >>Do we want to say anything about additional Presentation Fragments
    >>generated
    >>by scripts?
    >>
    >>
    >>       3. It SHOULD support other embedded elements (e.g., Flash, Applets,
    >>       etc.), and SHOULD provide a way to correctly route Actions triggered
    >>       by such elements.
    >>
    >>Personally, I would prefer to leave action routing from such elements for a
    >>later
    >>version of the specification.  I haven't seen any comments from others on
    >>this
    >>(though they may have been lost in the recent exchange :-).
    >>
    >>My proposal would be:
    >>
    >>3.  It MUST support other embedded elements (e.g., Flash, Applets, etc.),
    >>but
    >>need not provide a way to correctly route Actions triggered by such
    >>elements.
    >>
    >>Sean
    >>
    >>
    >>