[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: WSIA 5/10/2002: [wsia][wsia-requirements][R602]
Break 3) Into two requirements: Suggestion: 3. A WSIA Web Service MUST support embedded elements. These include: * Flash * Applets * Other A WSIA Web Services MAY support routing of actions triggered by embedded elements. Proposed: 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. -----Original Message----- From: Sean Fitts Sent: Fri 5/10/2002 12:05 AM To: Eilon Reshef; Monica Martin; wsia@lists.oasis-open.org Cc: 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 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