[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC