OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: WSIA 5/8/2002: [wsia][wsia-requirements][E922]


A WSIA compliant Web Service MUST provide the capability for Producers
to enable non-WSIA applications.
 
This does not say how the enablement occurs, just that it is up to the
service to provide the capability.  If there is a concern on precedent
(or politics), suggest inclusion in a non-normative section.
 
Throw darts everyone.
 
Thanks.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946

	-----Original Message----- 
	From: Rex Brooks 
	Sent: Wed 5/8/2002 2:23 PM 
	To: Vadhri, Srinivas; 'Beck, Stefan'; 'Timothy N. Jones';
wsia@lists.oasis-open.org 
	Cc: 
	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>
	
	
	--
	
	----------------------------------------------------------------
	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