[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: AW: AW: [wsia][wsia-requirements][E922]
I have to disagree. A positive statement may feel better, but the MUST NOT preclude sends the correct message--that we are accommodating legacy systems, not giving them the nod. Also, when one says enable this or that, the most common association made is that this is the approved, or, heaven forbid, the only application/service/bucket of stuff that the spec supports. What springs to mind is the situation where a host of potential supporters say, "Hey what about all that new REST, XMLP, Semantic Web stuff coming along? You mean we can't use that?" MUST NOT preclude" actually enables everything without giving the impression of any favored system, and it also serves notice that change is coming. Ciao, Rex At 10:17 AM -0700 5/8/02, Vadhri, Srinivas wrote: >I agree with Stefan - on both accounts. > >1. Positive formulations are better >2. the installed base of legacy systems is too big to ignore. Again, we are >talking about standards and very difficult to accommodate all, particularly >legacy systems which at the minimum do not even use XML-based >interfaces/connectors. > >Srinivas > >-----Original Message----- >From: Beck, Stefan [mailto:stefan.beck@sap.com] >Sent: Wednesday, May 08, 2002 9:40 AM >To: 'Timothy N. Jones'; wsia@lists.oasis-open.org >Subject: AW: AW: AW: [wsia][wsia-requirements][E922] > > >Tim, > >I still believe, that E922 is an important statement: >- from a marketing perspective: we should encourage companies to do steps >toward WSIA and therefore an explicit statement is helpful >- my company has lot of existing applications in our installed base and for >the acceptance of WSIA, E922 is an important requirement that is worth >mentioning > >And by the way, I think positive formulations (enable) are preferable to >negative ones (must not preclude) when you intend to convince a somebody. >Thats my position. > >But the majority has to decide... > >Stefan > > > >-----Ursprüngliche Nachricht----- >Von: Timothy N. Jones [mailto:tim@crossweave.com] >Gesendet: Mittwoch, 8. Mai 2002 16:23 >An: Beck, Stefan; wsia@lists.oasis-open.org >Betreff: Re: AW: AW: [wsia][wsia-requirements][E922] > > > >To me "enable" means positive support for something, "not preclude" is >neutral, and "preclude" means negative support (i.e., trying to prevent >something). I think the best slot for this one is in the middle. > >Of course, WSIA should also not preclude interactive web services from >working on Wednesdays, or in the southern hemisphere, but we don't mention >these specifically. To me the difference is that many people are concerned >about legacy apps fitting into the web services world, and so E922 is not >totally pointless (it may not be strictly "normative" but does have value >for the reader). > >On the other hand I'd be okay with it being removed from the official >requirements list altogether, since the default support for legacy apps, >Wednesdays, the southern hemisphere, and everything else should be "neutral" >unless it deserves special attention for some reason. > >Tim > >> That was my intention. I'm not expecting a chapter how to wrap legacy >> applications within the specification. As I understand the word "enable", >it >> means something like "allow" respectively "not to preclude". But I'm not a >> native speaker:-) >> -----Ursprüngliche Nachricht----- >> Von: Rich Thompson [mailto:richt2@us.ibm.com] >> Gesendet: Mittwoch, 8. Mai 2002 14:34 >> An: wsia@lists.oasis-open.org >> Betreff: Re: AW: [wsia][wsia-requirements][E922] >> Do we really expect the specification to do anything to enable this >> wrapping of legacy applications? I think the intent to to not preclude >> developers from interacting with any back end system they want to. >> >> "Beck, Stefan" >> <stefan.beck@sap. To: >> wsia@lists.oasis-open.org >> com> cc: > > Subject: AW: >> [wsia][wsia-requirements][E922] >> 05/08/2002 03:28 >> AM >> >> >> Whats about: >> The specification MUST enable Producers to provide existing legacy >> applications and infrastructure as WSIA compliant Web Service. >> Stefan >> -----Ursprüngliche Nachricht----- >> Von: Timothy N. Jones [mailto:tim@crossweave.com] >> Gesendet: Montag, 6. Mai 2002 20:00 >> An: wsia@lists.oasis-open.org >> Betreff: RE: [wsia][wsia-requirements][E922] >> Is there a reason this shouldn't be a "must", i.e.: >> The specification MUST not preclude Producers from providing the >> capability to support legacy applications and infrastructure. >> As long as the protocol between Consumer and Producer is WSIA, it >shouldn't >> matter what else the producer is doing on the backend. >> Tim >> > Dan, I can see your perspective, but consider the consequences if we >> produce >> > a specification that prevents us from integrating with legacy >> applications. >> > Although we are in the domain of web services, the world will not become >> > fully WSIA aware for several years, and many of the implementations will >> be >> > producers exposing existing applications. >> > Without the ability to integrate the adoption rate will be low, which >> will >> > lead us down the path to obscurity. >> > I support Eilon's reworded statement, though I'm not sure that >> > 'infrastructure' adds anything to the requirement. >> > Regards >> > Greg >> > -----Original Message----- >> > From: Dan Gisolfi [mailto:gisolfi@us.ibm.com] >> > Sent: Monday, May 06, 2002 4:32 AM >> > To: wsia@lists.oasis-open.org >> > Subject: Re: [wsia][wsia-requirements][E922] >> > As we are dealing with the domain of Web Services, an assumption should >> be >> > made that the spec should pertain to any Web Service. Therefore, I see >no >> > need for the spec to specifically call out legacy applications and >> > infrastructure. The spec will pertain to any software component that can >> be >> > described using a Web Services facade. >> > Therefore I do not see a need for this requirement. I motion for >> deletion. >> > Dan Gisolfi >> > To: wsia@lists.oasis-open.org >> > cc: >> > Subject: [wsia][wsia-requirements][E922] >> > E922 >> > Producers SHOULD provide the capability to support legacy applications >> and >> > infrastructure. Debate: GG, ER, DG, SB, TJ. >> > This seems to be a requirement from a tool and not necessarily from the >> > specification. >> > Try: >> > The specification should not preclude Producers from providing the >> > capability to support legacy applications and infrastructure. >> > ---------------------------------------------------------------- >> > 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> >> ---------------------------------------------------------------- >> 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> >> ---------------------------------------------------------------- >> 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> > > > >---------------------------------------------------------------- >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> > >---------------------------------------------------------------- >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