[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: WSIA 5/10/2002: [wsia][wsia-requirements][R602]
Monica, thanks. This does a much better job of capturing my intent. Sean At 06:29 AM 5/10/2002 -0700, Monica Martin wrote: >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> > > > > >---------------------------------------------------------------- >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