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>
|