|
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...
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 ECMAScript as an associated scripting language, and
MUST include a way
to correctly route Actions triggered 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.
-----Original Message-----
From:
Monica Martin [mailto:mmartin@certivo.net]
Sent: Thursday, May 09,
2002 7:13 PM
To: Sean Fitts; Eilon Reshef;
wsia@lists.oasis-open.org
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; wsia@lists.oasis-open.org
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'; wsia@lists.oasis-open.org
>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:sean@crossweave.com]
>
Sent: Wednesday, May 08, 2002 5:57 PM
>
To: Eilon Reshef; wsia@lists.oasis-open.org
>
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:sean@crossweave.com]
>
Sent: Wednesday, May 08, 2002
2:14 PM
>
To: Eilon Reshef; 'Rich
Thompson';
>wsia@lists.oasis-open.org
>
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:sean@crossweave.com]
>
>
>
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>
|