New CR issue and Re: service and binding name shown as QNames in example - should be NCNames

Dear Graham,

Thanks for this, it's very helpful.  Some notes below, though.  For one thing, this may have turned up an issue in the specification related to the "defaulting" of the pattern attribute on operation.

The example seems not to have received due attention, perhaps because it's associated with the controversial features&properties issue.

On Tue, 6 Jun 2006 15:51:13 +0100
"Graham Turrell" <gturrell@googlemail.com> wrote:
>Here's a summary of changes to my copy of the pseudo-wsdl2:
>
>- added xnlns:tns declaration
>- removed xmlns:ns1 - redundant

Okay.

>- added xsi:schemaLocation (may wish to remove that from the
>pseudo-wsdl however)

Not really needed; it's a hint in any case.  No?

>- changed interface name attribute from QName to NCName
>- operation pattern attribute added (mandatory)

Okay.  There's an oddity here, though.  I thought that I had lost the argument to make the pattern attribute required (the property which it populates is required, but there is a defaulting rule in section 2.4.3 which is never invoked because there's no room for it to be invoked due to the wording of 2.4.2.2).

So the spec has either a redundant, unused defaulting rule, or in the editing process we somehow managed to drop the optionality of the pattern *attribute*.  Issue.  Not related to the editorial issue of the broken example.

>- binding name attribute changed from QName to NCName
>- binding type attribute added - mandatory

Correct.

>- service name attribute changed from QName to NCName
>- endpoint name attribute added (mandatory)

Correct.

>- (also, endpoint binding attribute prefix changed to tns. Prefix ns1
>probably redundant here).

Simpler is better.

Since Graham's done the work for us, I recommend that we on the whole adopt his pseudo-wsdl2 to repair this example, with the following changes:

1) drop the addition of xsi:schemaLocation

2) drop the addition of the pattern attribute, following (the expected) resolution of the current specification inconsistency (which should be opened as a separate issue against CR)

New Issue description: operation@pattern is now a required attribute, but the rules for binding to the associated property include a default.  Memory suggests that this issue was resolved in favor of permitting the pattern attribute to be absent for a particular special case: in-out.  This means, though, that the pattern attribute should be marked OPTIONAL, not required.  The associated property should remain required.  The defaulting rule in the mapping section then becomes a live rule.

Alternate resolution (hey, this is what *I* argued for all along, okay?): drop the language supplying a default, which is currently never used due to the fact that the pattern attribute is required.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 6 June 2006 15:29:31 UTC