- From: Josh@oklieb <josh@oklieb.net>
- Date: Fri, 17 Mar 2006 14:35:06 -0500
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: public-sws-ig@w3.org
Bijan, I appreciate your comments and provide some further clarifications below: On Mar 17, 2006, at 1:34 PM, Bijan Parsia wrote: > On Mar 17, 2006, at 12:27 PM, Josh@oklieb wrote: > >> This discussion is also giving me an inclination towards >> preemptive deletion of sws-id emails, which is unfortunate. > > That is unfortunate. Though, overall, there's not too much traffic, > and really only one determined disrupter. > >> Between the confusion of terms (as pointed out, using composition >> for binding) > > Again, single source. > >> and "descent" to XML Schema arguments, > > Hmm. What's this? Pointer? For example, one XML form of an invocation message (e.g. SOAP, standalone WSDL) versus another when much the same information needs to be carried anyway. Sometimes this seems to involve equating SOAP with a simple form of SOAP RPC, which is unfortunate for a more generally useful technology. > >> it can't be said to advance the cause. >> >> It is rather amazing (heartening or disheartening, I'm not sure) >> to see arguments rehashed which have been going on in the OGC >> (Open Geospatial Consortium) for years. For example, the use of >> private XML message schemas versus SOAP formulations, whether >> URLencoded service invocations using HTTP GET are still important, >> equating SOAP/WSDL with RPC and in turn with the full spectrum of >> Web service possibilities, the idea that the useful information >> abstractions of WSDL should command slavish devotion to its >> syntax (as well as claim to completeness). > > Er...where was this last? > > Personally, I don't see any point in departing from WSDL unless > necessary. Certainly not at the W3C. The mindshare is compelling. WSDL has it's place, certainly, but it is neither as flexible nor as automatic as some vendors of development systems would have it believed. Handling of optional parameters is poor, for example, and dynamic binding is quite limited in practice. The service descriptions used for OGC services contain much of the same information as in WSDL, plus much other information. Some attempts to stuff that information into the WSDL syntax have produced WSDL documents which are as non-standard as they are disfunctional. > >> In truth, and disjoint vocabulary aside, we are all fairly well >> agreed on the general information which is needed to productively >> discover, bind, and consume a remote service over the Web. > > I'm not so sanguine. And, of course, there are details and there > are details. > >> We should focus on the substantive general questions that remain. >> For instance, is it advisable to abstract away all knowledge that >> an operation is being invoked on a remote service over the Web >> (probably not)? Should services be self-describing (probably so)? > > What does this mean, concretely? It seems like everything points to > their *not* being *self* describing (hence, all the > descriptions :)). Since we don't have *access* to the "self" of the > service, it seems like they can't be. All OGC services support a "GetCapabilities" operation (and soon a "GetWSDL" operation). Practically, any other arrangement ends up in some form of disconnection between the service instance and its description, various in-progress cataloguing projects aside. This is particularly important for services with dynamic coupled content. > >> Is coupled content an important part of service semantics (yes >> and yes)? Does WSDL impart all the information needed (for a >> machine) to use a remote service outside of a small circle of >> friends (no). > > Hmm. This is a bit brief. There's a version of the notion of "all > the information" wherein the answer is yes. E.g., can a WSDL, using > the default vocabulary, be sufficient to using (i.e., invoking) the > service? Obviously yes, even outside a small circle of friends. > Does pure standard wsdl have any way for me to indicate the > *purpose* of so invoking it? Not in any way that doesn't require a > person to read some text. (It's not *friendliness* but *out of band > knowledge, that circumscribes the set of machines that can sensible > use the service.) > > Actually, that's not quite true. In principle, if I support the > same interface (even though I'm a different service) you can use me > in the same way. So once a program "knows" it wants to invoke an > operation of a certain interface, it can (in principle) do so > regardless of the endpoint, binding (assuming it supports a > binding), or Service. This isn't nothing, but it's not a whole lot. > One thing we might like is, given that we're want to invoke > operation A in interface B, that we would be equally ok with > invoking operation C in interface D. (And eventually, instead of A, > invoke some composition of E, F, G, H, I...) There is a theory, I suppose, that everything needed to call an operation can be defined in the interface, but I would assert that is only achievable in the most simple of cases concerning the domains of and correlations between the (input and output) parameters. It is not so valuable to develop software which can only invoke a single operation on a single interface with a single set of parameter options returning a single type of content (e.g. street features from the City of Cambridge) and cannot adapt on the basis of service information to another service (e.g. with street features from the City of Brookline). Even so, development of that software would require knowledge about the service which is generally beyond the (necessary but not sufficient) descriptive capabilities of WSDL. There is certainly no such thing as the perfectly soft client and will alway be some limited domain of service capabilities that any one piece of software can be developed for, but both OGC standard service types and OWL-S VM's (to a limited extent as yet) have provided some demonstration of a software client being able to "use" any of a collection of services using extra-WSDL metadata. The verb "use" is probably a term we are not at all agreed on. I take it to mean something more than "invoke in a syntactically correct manner" and something less than "understand fully the purpose of the invocation and response". Perhaps we should simply (!) work towards service descriptions to enable development of client software which allows users (orchestrators?) to get as many different tasks done as possible using as many different services as possible, in other words keep enlarging the circle of friends... > >> Is it important to represent in service information how a service >> processes inputs to generate outputs (yes, different geocoding >> services for example have their own idiosyncratic heuristics >> irrespective of the syntax)? Where are syntax standards useful for >> interoperability? Should we get all wound up about whether this >> additional service information is contained in a WSDL >> <definitions> element, referenced from within a WSDL >> <definitions>, outside of a WSDL <definitions> (not really that >> important a question)? > > In a sense not all that important. In a sense it has a strong > default answer (in). The main point is to do so in whatever way is > politically most acceptable (in the sense of not alienating vendors > or users). > > Cheers, > Bijan. >
Received on Friday, 17 March 2006 19:35:26 UTC