[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
Complete support sounds like a plan to me, too. Ciao, Rex At 9:27 AM -0700 5/10/02, Sean Fitts wrote: >Ravi, thanks. Your description of providing "support" for a format vs. >just passing it along (and making sure not to muck it up) is exactly >what was lurking in the back of my mind. > >I guess the thing that confused me was that we explicitly called out >Action routing, but failed to mention all the other aspects of providing >"support" for a given element. I wasn't sure if this was intentional or >just because the other aspects are handled by other requirements. > >For instance, if the WSIA supported Action routing from scripts, but >did not support adaptation of generated markup, would it meet this >requirement? I don't think it should, but I'm not entirely sure that this >is true as currently worded. > >So, 2 questions - do others agree that we need to provide "complete >support" (as outlined by Ravi below) for scripts? If not, why not? > >Any thoughts on the current wording and whether it captures this intent? > >Sean > >At 09:04 AM 5/10/2002 -0400, Ravi Konuru wrote: > >> > Do we want to say anything about additional Presentation Fragments >>generated >>> by scripts? >> >>We MUST support them and I am assuming that by support, we mean action >>routing, interpretation, and adaptation. As you pointed there is so much >>use of it that we cannot ignore. However, in general wrt javascript do we >>explicitly mention that there may be guidelines on javascript coding so >>that we can do routing? >> >>After reading through your version of reqmt 3. It seems we need to >>distinguish between delivering a format opaquely/pass-through vs what I >>defined above as support. Should we use the words "Carry or Opaquely >>transport" and "Support" to distinguish the two or am I missing something? >> >>regards, >>Ravi Konuru >>eBusiness Tools and Frameworks, IBM Research >>office: 914-784-7180, tieline 8-863-7180; fax -3804 >> >> >> >> >> Sean Fitts >> <sean@crossweave. To: Eilon >>Reshef <eilon.reshef@webcollage.com>, "'Monica Martin'" >> com> >><mmartin@certivo.net>, wsia@lists.oasis-open.org >> cc: >> 05/10/2002 03:05 Subject: RE: WSIA >>5/9/2002: [wsia][wsia-requirements][R602] >> AM >> >> >> >> >> >> >> >>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