Re: Minority objection to requiring unique GEDs or required feature to distinguish operations

Amy, after this pretty long time I finally got to read this reply of
yours and I think I see your point now.

I think to you the situation boils down to either providing a unique URI
that none of the "random strangers" knows anyway or not providing

In both cases a random stranger will not be able to connect to the
system so there's no issue here. 

As for implementing a toolkit, yes I'd allow arbitrary URIs for the
dispatch mechanism by instructing the toolkit that I know the URI. The
intent is that when the toolkit allows me to invoke a WSDL operation,
I'd like to be able to tell it which one it is, because I know it

The problem with SHOULD is - what is the behavior in case the dispatch
mechanism is unspecified? In such a case, if I was a toolkit, I'd spew
out a warning that the client application using me better know about the
particular dispatch mechanism of the particular service. So far it's the
same as handling unknown, mandatorily explicit URIs.

But finally, without the requirement, one cannot tell whether two
different services with the same binding use the same dispatch mechanism
or not, if one is not explicitly mentioned. I'm slightly uneasy about

But I'd have no significant problem (and certainly no objection any
more) to making the requirement a recommendation (SHOULD).

Best regards,


On Fri, 2004-08-13 at 18:21, Amelia A Lewis wrote:
> On Fri, 13 Aug 2004 11:55:41 -0400
> Mark Baker <> wrote:
> > On Fri, Aug 13, 2004 at 10:53:39AM -0400, Amelia A Lewis wrote:
> > > We have clients who will *not* be able to use a standard URL
> > > describing a dispatch mechanism, because they aren't using one.
> > 
> > Of course they're using a dispatch mechanism!  Without one, the message
> > can't get to the application.
> They're certainly dispatching.  That doesn't mean that they use a single
> mechanism (as opposed to several).
> > Could you describe in detail what these customers of yours are trying to
> > do please?
> Sorry, no.  One of them I can't describe, because I don't understand how
> it works.  The other two I've described approximately.  I'll try, without
> breaching confidentiality, to describe a little more.
> It's interesting that there are two of them, actually.  One of them uses a
> pretty easy-to-describe algorithm; there's a field (pretend it's called
> "command") in each message that identifies it.  Always the same xpath
> (this is rpc in wsdl 1.1, so better to say always the same xpath apart
> from the root element, taking the first child of the body as the root
> element).
> It wouldn't be too hard to generate a URL that describes this.
> Now, the other uses multiple fields, and the second (and greater than)
> fields depend upon the content of the first field.  That is, one
> particular operation may be identified by the value "1" in field "root/x"
> plus the value "7" in field "/root/a/b/c", whereas another operation is
> selected by the value "2" in field "root/x" and the value "4" in field
> "root/l/m".  Actually, it's more complex than that, but that's the general
> idea.
> Question: should there be one URL that says "operation identifier
> contained in message"?  Or does every XPath need a different URL?  Or is
> there some middle ground, such as a URL per algorithm to determine the
> location of the operation indicator?  Note that, in no case are any of
> these "operation names" in the WSDL sense; it is possible to build a table
> that maps these indicators (singular or plural per message) to an
> operation.  Big table, in two cases (one I haven't described; I assume
> it's table-driven).
> Now, the fact is that nobody is going to connect to these systems (these
> are legacy systems, mind, not new design; the goal is to describe them,
> then modify and modernize them over time) without knowing stuff, and
> putting this sort of complex stuff into the WSDL is just pointless.  I can
> pretty much guarantee that these folks are all just going to use a
> facility (which *we* will certainly offer them, since we wanna keep their
> business) to either turn off conformance with Stupid Requirement, or to
> specify an Alkahest URL that dissolves requirements.  If other vendors
> don't do the same, fine, we have a nice value-add to keep them locked up. 
> But this is *exactly* the kind of thing that leads to incompletely
> implemented specifications, because the requirement for this is *STUPID*. 
> I'm rather surprised that more people aren't bothered by it; maybe there
> aren't that many folks helping build out integration or facades for legacy
> systems?  I wish *I* could write all new software whenever I wanted. 
> *sigh*
> So ... there are folks who won't bother creating a specific URL for their
> specific case, because it already requires special work to connect to the
> service, and the point of the WSDL isn't to allow random strangers to
> connect, it's to document the system as it's modernizing, with the goal of
> *eventually* allowing random strangers who use toolkits created by purists
> (who can't be bothered to permit customers to deal with problems
> pragmatically) to connect.  Eventually.  Eventually, probably, they'll
> adopt the best practice, revising the messages and making sure that things
> are done in a well-known, easily understandable way.  But they're not
> rewriting their bloody systems 'cause a bunch of spec-writers decided to
> create a Stupid Requirement.  They'll work around that one.
> Amy!

Received on Sunday, 5 September 2004 00:57:37 UTC