Title: Message
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.
-----Original Message-----
From: Sean
Fitts [mailto:]
Sent: Friday, May 10, 2002 12:28
PM
To: Ravi Konuru
Cc:
Subject: RE: WSIA 5/9/2002:
[wsia][wsia-requirements][R602]
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
> <>, "'Monica Martin'"
>
com>
<>,
>
>
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
>
>
> -----Original
Message-----
>
From: Monica Martin [mailto:]
> Sent: Thursday, May
09, 2002 7:13 PM
> To: Sean Fitts; Eilon Reshef;
> Subject: WSIA 5/9/2002:
[wsia][wsia-requirements][R602]
>
Agreed.
>
Eilon, are we close?
>
>
Thanks.
>
Monica J. Martin
>
Program Manager
>
Drake Certivo, Inc.
>
208.585.5946
>
>
-----Original Message-----
>
From: Sean Fitts
>
Sent: Wed 5/8/2002 10:44 PM
>
To: Monica Martin; Eilon Reshef;
>
>
Cc: Monica Martin
>
Subject: Re: WSIA 5/8/2002:
>
[wsia][wsia-requirements][R602]
>
>
>
>
This make sense. My main goal was to point out that
>
the
>
"presentation
>
fragments" referred to below consist only of "markup".
>
They
>
don't today
>
and they won't in the future. I think we all agree
>
that some of
>
the
>
non-markup
>
bits will be opaque (what we have been calling
>
"binary"), but
>
that others
>
will not be.
>
>
I do think that it is useful to map these concepts into
>
the
>
specific set of
>
technologies in use today (even if that mapping is
>
temporary).
>
It helps serve
>
as a sanity check that what we do will be relevant to
>
web
>
application
>
developers
>
(not to mention the fact that I think better with
>
concrete
>
examples :-) ).
>
>
In terms of the goals you outline below, I would add:
>
>
* Provide a mechanism to support
modification of
>
Presentation
>
Fragments based on Consumer supplied criteria.
>
>
Note that this leaves aside the issue of where such
>
modifications are
>
performed.
>
>
Sean
>
>
At 08:18 PM 5/8/2002 -0700, Monica Martin wrote:
>
>One thing that this lengthy and varied discussion has
>
clearly
>
shown,
>
>that we may never be able to define a comprehensive
>
set of
>
client-side
>
>scripting languages unless for an instant (Sorry,
>
everyone I am
>
not a
>
>programmer by choice). Perhaps we should concentrate
>
on what
>
this
>
>requirement is trying to accomplish:
>
>
>
>* Provide a mechanism to support
triggered
>
actions
>
>* Provide support for Presentation
Fragments
>
>* Provide support for embedded
Presentation
>
Fragments
>
>
>
>As for the modifications and/or adaptions that were
>
discussed,
>
this
>
>detail may be better left to subcommittee tug-of-war.
>
Suggest
>
we
>
>concentrate on the what, before the how.
>
>
>
>Thanks.
>
>Monica J. Martin
>
>Program Manager
>
>Drake Certivo, Inc.
>
>208.585.5946
>
>
>
>
>
>-----Original Message-----
>
>From: Eilon Reshef
>
>Sent: Wed 5/8/2002 3:38 PM
>
>To: 'Sean Fitts';
>
>Cc:
>
>Subject: RE: [wsia][wsia-requirements][R602]
>
>
>
>
>
>
>
> My thought was around
people that use scripts
>
like
>
this:
>
>
>
> <script>
>
> var target = " http://" + gMyDomain +
>
"/mypage.rgb?page=" +
>
>document.form[1].pageNumber.value;
>
>
>
> document.location =
targert;
>
> </script>
>
>
>
> My intent was to
formulate a part of the
>
requirement
>
that
>
>clearly states that WSIA cannot expect Consumers to
>
automatically
>
>rewrite this action to point back to the Consumer.
>
>
>
> Does this make sense as
the intent of this
>
part of the
>
>requirement?
>
>
>
> As for a proposed
solution, one can consider
>
three
>
options:
>
> 1. Disallow such cases
and other such
>
constructs
>
(which is
>
>always the last resort).
>
> 2. Define a meta-language
that does not
>
require
>
changes to the
>
>script (assuming it's a script that was written
>
beforehand),
>
and tries
>
>to capture the replacement locations externally (a-la
>
adaptation).
>
>However, the halting problem (;-) does argue that
>
there will
>
still be
>
>cases that the external language won't be able to
>
address.
>
> 3. Ensure that enough
information is passed
>
to the
>
Producer so
>
>that when it either writes new applications or when it
>
needs to
>
adapt
>
>cases like this, it would be technically possible.
>
>
>
> Any thoughts?
>
>
>
> Eilon
>
>
>
>
-----Original Message-----
>
>
From: Sean Fitts [
>
mailto:]
>
>
Sent: Wednesday, May 08, 2002 5:57 PM
>
>
To: Eilon Reshef;
>
>
>
Subject: RE:
>
[wsia][wsia-requirements][R602]
>
>
>
>
>
>
At 04:51 PM 5/8/2002 -0400, Eilon
>
Reshef
>
wrote:
>
>
>
>
>
>
>
>
I think I see your point (I
>
thought of
>
>modification as semantic versus syntactic), how about
>
the
>
following
>
>wording (which still puts the Customization issue
>
aside):
>
>
>
>
>
>
One small tweak, the modifications
>
may be
>
semantic, but
>
>the semantics are
>
>
largely implied and will likely need
>
to be
>
described
>
>externally (ala the adaptation
>
>
description in WSXL).
>
>
>
>
I guess I don't see a lot of
>
difference here
>
between
>
>this type of modification and
>
>
general markup modification. Both
>
contain
>
semantic
>
>information, both require
>
>
some sort of locator to identify the
>
sections
>
>implementing a given semantic
>
>
operation, and in both cases, the
>
semantics
>
are opaque.
>
>
>
>
>
>
>
>
>
>
>
>
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 JavaScript
>
as an
>
associated
>
>scripting language. Such support MUST include a way to
>
support
>
Actions
>
>triggered by scripts. However, it SHOULD NOT be
>
assumed that
>
the
>
>Consumer is aware of the semantics of scripting
>
elements.
>
>
>
>
>
>
Given the parallel between semantics
>
of
>
scripting
>
>elements and semantics
>
>
of other elements (such as markup
>
and/or
>
actions), I
>
>still don't see the need
>
>
for the second statement. However,
>
in this
>
form it
>
>seems a lot more benign
>
>
(at least to my eye).
>
>
>
>
>
>
>
>
>
>
3. It SHOULD support embedded
>
binary
>
>presentation elements (e.g., Flash, Applets, etc.).
>
>
[Optional/Debate: Such
>
support SHOULD
>
provide a
>
>way to support Actions triggered by such elements.]
>
>
However, it SHOULD NOT be
>
assumed that
>
the
>
>Consumer modifies the binary elements in any way.
>
>
>
>
I personally think it makes
>
sense to
>
favor a
>
>single technical approach that captures both (2) and
>
(3), but I
>
also
>
>don't see it as a high-level requirement but rather as
>
a
>
technical
>
>preference.
>
>
>
>
>
>
Could you elaborate on this? I'm not
>
sure I
>
understand.
>
>Thanks.
>
>
>
>
Sean
>
>
>
>
>
>
>
>
-----Original
>
Message-----
>
>
From: Sean Fitts [
>
> mailto:]
>
>
Sent: Wednesday, May
>
08, 2002
>
2:14 PM
>
>
To: Eilon Reshef;
>
'Rich
>
Thompson';
>
>
>
>
Subject: RE:
>
>[wsia][wsia-requirements][R602]
>
>
>
>
>
>
At 01:55 PM 5/8/2002
>
-0400,
>
Eilon Reshef
>
>wrote:
>
>
>
>
>
>
I am not suggesting
>
that the
>
Consumer is
>
>not allowed to change JavaScript, rather the
>
suggestion is that
>
we
>
>wouldn't assume that it should. To me, that's because
>
correctly
>
>analyzing code constructs (in any language) without
>
executing
>
them is
>
>anywhere from hard (from a practical perspective) to
>
impossible
>
(from a
>
>theoretical perspective, as Theory of Computation
>
shows).
>
>
>
>
I don't see a
>
connection
>
between
>
>supporting modification of JavaScript
>
>
(which I agree is an
>
open
>
issue) and the
>
>need to support complete,
>
>
path wise analysis of
>
it.
>
Leaving the
>
>halting problem aside for a bit, it
>
>
would seem possible
>
to extend
>
the
>
>Adaptation Description Language
>
>
proposed by IBM to
>
include
>
JavaScript
>
>modifications along with XML
>
>
and CSS ones.
>
>
>
>
>
>
>
>
>
>
This is not to say
>
that WSIA
>
can't
>
>define an interface that uses JavaScript (e.g., I
>
assume the
>
committee
>
>may decide to define JavaScript functions, events,
>
etc.), but I
>
guess
>
>that the question is can we require the Consumer to
>
analyze
>
JavaScript
>
>code to support action routing, for example?
>
>
>
>
Again, I don't see
>
how leaving
>
the
>
>second sentence out leads to
>
>
*requiring* the
>
Consume to
>
analyze or
>
>even modify JavaScript. Such a
>
>
statement would seem
>
to need a
>
positive
>
>assertion that such modification
>
>
*is* a requirement
>
(something
>
which
>
>again, I view as open).
>
>
>
>
>
>
>
>
>
>
Customization is
>
definitely
>
something
>
>that we will be discussing in the Customization
>
sub-committee.
>
My
>
>working assumption is that the requirement below is
>
rather
>
generic, and
>
>applies to anywhere from the scope of WSIA in general,
>
to
>
action
>
>routing, unique tokens, etc., and that it might be
>
changed as
>
the
>
>Customization sub-committee proceeds.
>
>
>
>
I guess my take is
>
that it is
>
too
>
>generic. It seems to be trying to
>
>
take a half step and
>
would
>
result in
>
>muddying things instead of making
>
>
them clearer. If it
>
really
>
doesn't
>
>place any restrictions one way or the
>
>
other on our work,
>
then it
>
doesn't seem
>
>like a requirement and I would
>
>
argue it should not
>
be
>
included.
>
>
>
>
>
>
Sean
>
>
>
>
>
>
>
>
>
>
Eilon
>
>
>
>
-----Original
>
Message-----
>
>
From: Sean Fitts [
>
> mailto:]
>
>
>
>
>
>
2. It MUST support
>
JavaScript
>
as an
>
>associated scripting language and MUST provide a way
>
to support
>
actions
>
>triggered by scripts. [Optional/Debate: However, it
>
MUST NOT be
>
assumed
>
>that scripting elements are modified by the Consumer
>
in any
>
way.]
>
>
>
>
Why do you feel that the second "MUST
>
NOT"
>
statement is
>
>necessary?
>
>
To me it seems overly restrictive
>
since it
>
impacts both
>
>what types of
>
>
customization we will support and
>
where the
>
>customization will occur.
>
>
My understanding is that both of
>
these issues
>
are still
>
>up for debate/
>
>
description in the customization
>
sub-group.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------
>
>
>To subscribe or unsubscribe from this elist use the
>
subscription
>
>manager: < http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
