After offline discussions, it has been agreed that a non-scripted solution is appropriate. The attached namespace.md file describes the solution to be implemented. This solution relies on changes to the ESDL definition and binding; it does not define a new scheme as initially proposed. Also, no conditional content is supported; the ESDL definition and binding both support service- and method-specific rules.

I would say that should '@ver' be part of the string, not something we generate.  The version itself should be supported for substitution.

I'm really trying to avoid complex configuration schemes when we have a scripting platform that can be made to allow you to do whatever you want.  Basically we can support some substitution but after a point we should have a way of doing it in script instead.  Even if a simple script to set the namespace is the only script the service uses.  More and more the scripting should be the focus of most flexibility.

We may need to add a script that runs at service init time.

I would say:

1. Provide a simple explicit namespace configuration with variable substitution.

2. Perhaps allow the service and method namespaces to be defined separately.

3. Provide a way for the namespace to be completely overridden in script.
   A. open Jira(s) for service and method init scripts, including service level namespace setting
   B. open a Jira for adding method level namespace override in scripts 

If Marius doesn't get what he needs from 1 and/or 2, then we can discuss accelerating 3.  For example we could do the method runtime namespace part of #3 sooner than the rest.

Upon further review, the inclusion of {$method} must be conditional in order to recreate the current default behavior. EsdlBindingImpl::generateNamespace may be called with a method name, when generating for an individual method, or without, when generating for the service. This complicates matters because the delimiter between service and method names is omitted when method is unspecified.

This change must introduce markup that enables the delimiter's inclusion to be conditional upon the method's inclusion. A pattern like `urn:mydomain:{$service}[:{$method}]` could produce `urn:mydomain:myservice` for a service's WSDL and `urn:mydomain:myservice:mymethod` for a method's WSDL. This markup includes the delimiter when the method name is not empty and omits the delimiter when the method name is empty; a non-empty variable value will always be included.

 I have a couple questions about implementation. First, I chose `full` for the scheme value because it can be a full, or complete, namespace, but is there a better name. Second, the inclusion of version in the default namespace is `@ver=<client-version>` but I'm unsure how much, if any, of `@ver=` should be part of the substitution and how much we should expect in the template.