- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Fri, 30 May 2003 12:23:48 -0600
- To: www-ws-arch@w3.org
> -----Original Message----- > From: Cutler, Roger (RogerCutler) > [mailto:RogerCutler@chevrontexaco.com] > Sent: Friday, May 30, 2003 1:48 PM > To: Champion, Mike; www-ws-arch@w3.org > Subject: RE: "Conformance" discussion on WSA document > > 1 - "language that can be mapped into WSDL" -- this sounds > backwards to > me. If a language is richer than WSDL, I think WSDL might be mapped > into it but probably not the other way around. Yeah, I think you're right ... at least the original wording was too rough. This is probably too complex an issue to be used as an example here. I put it in because of our discussions about the WS-Security people not defining a WSDL description for their headers. It's the kind of thing that it would be good if we could say "normatively." > Personally I am very uncomfortable with anything that equates "Web > service" narrowly with "WSDL", Again, this probably isn't the right place in the document to raise such a complex issue, but I came away from the discussions with the WSDL people thinking that we can accomodate both Roger's view that WSDL itself isn't necessary to the definition of a Web service, and the common view that something LIKE WSDL is necessary to specify a web service interface in enough detail so that machines can interoperate. That is, WSA could define a conceptual model that is compatible with WSDL but is rich enough to encompass examples such as the the RESTful graphic processing service use case, and make that "normative." Whether the conceptual model was actually implemented/exchanged in WSDL, DAML-S, IDL, or whatever is not architecturally important, but the necessity of rigorously defining services, interfaces, bindings, and operations *is* critical. IMHO, of course, I know we don't have consensus on this. > 2 - "Conversely, the architecture notes that a message is a unit of > interaction between software agents. This means that the > architecture is > not concerned about messages between objects that are within an > implementation of a Web service.". I'm sorry, I guess I just don't > understand this -- how one statement follows from the other. Maybe I was lazy and trying to preserve too much of the previous contents of section 2.1. I don't have strong feelings about this, we can remove it if it is confusing. > 3 - "We also state that messages have a message sender; any > specification realizing this architecture that does not > permit a message > to be associated with its sender is not in conformance with the > architecture." Do we really mean that? I think that we have > seen usage > cases in which anonymous access to Web services is a requirement. > Health care industry, for example. Perhaps I am not understanding > correctly what is meant? Same response as above. The idea here is to find some examples where WSA could give normative guidance to WS specwriters. Let's think of better ones, by all means! > > 4 - "Unlike language specifications ... corresponding relationships > implied by conformant specifications." This looks to me like it's > basically in the right direction, but that as it is currently stated I > think it may be too strong because it seems to imply that > EVERY concept and relationship must be expressed in EVERY spec. GAG!! Right, see the note on this ... I was looking for help saying the "less strong" version more clearly. > > 5 - ... Maybe that somebody look at > the infant RM section I contributed and mess around with it so it actually does make > some reasonable normative statements. Good idea. > That is, a visionary architecture that ignored > current reality > would be ... useless. An architecture that provides a conceptual > framework for current specs and no guidance for future specs would be > ... Embarassing. Well put! I agree that the "vision" vs "consensus" distinction doesn't work and needs help. Saying exactly what you've said may be the best way to say what needs to be said here. >
Received on Friday, 30 May 2003 14:23:55 UTC