Title: Message
How about breaking this into two separate requirement that represent 1-3
and 4?
I would be slightly concerned with a requirement that hints that we
should put up guidelines or restrictions for developers. In fact, I believe that
the business requirement should be "do not restrict the way
people do things in any way". If us, as a technical committee, cannot answer
that business requirement, that's fine (we won't be able to answer all), but
it's better to clearly put a stake in the ground as to what we are
trying to achieve, and then discuss on priorities. Same goes with not
fully supporting Flash/Applets/etc. - they should be supported. (I
did not fully understand your suggestion below, so I might still be missing
something.) If we (or: a particular technical approach) can't manage to, that's
our fault, but that doesn't mean that the requirement is not there... I believe
that otherwise, we run into a risk that the spec will eventually be dominated by
clean technical ideas, but will end up not meeting the real business
requirements.
Eilon
-----Original Message-----
From: Ravi Konuru
[mailto:]
Sent: Friday, May 10, 2002 3:16
PM
To: Eilon Reshef
Cc: 'Sean Fitts';
; Kurt Cagle
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'"
<>,
Ravi
ollage.com>
Konuru/Watson/IBM@IBMUS
cc:
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.
-----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>
