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