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]
Sean,
> cHTML
Unless there is a requester or we have a convincing reason lets not
consider it. I don't have one.
> 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