[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
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: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 concreteexamples :-) ).
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 bedescribed
>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 extendthe
>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>
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC