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