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>
