Jeremy,
> The Binding component in the WSDL spec defines the name property as a
> QName. The XML representation is defined as an NCName. Which I
> interpret to mean that the namespace of the QName is always the
targetNamespace.
Yes. In Part 1, for Interface, Binding and Service there is a subsection
under XML Representation that confirms your interpretation. EG:
"The name attribute information item together with the targetNamespace
attribute information item of the [parent] description element information
item forms the QName of the interface."
> It turns out that Woden DOMWSDLParser assumes the name attribute is a
> well formed NCName and just passes its value [Attr.getValue()] into
> the localpart param of the QName ctor.
>
> So I think we need to fix Woden to report an error at this point.
Remember that Woden validation is performed by syntax validation via XML
Schema validation, then semantic validation via the WSDLDocumentValidator
and WSDLComponentValidator. So with the WSDLReader validation feature
enabled, this type of error will be reported by schema validation (e.g. if
the value of the 'name' attribute of <service> is 'xyz:reservationService'
the error reported is: 'xyz:reservationService' is not a valid value for
'NCName'.).
However, Woden will still return a DescriptionElement so even if this error
is reported by schema validation, a QName will still be created with
"xyz:reservationService" as its local part. This is not a QName error (at
least, it doesn't seem to violate javax.xml.namespace.QName as defined by
J2EE 1.4 or J2SE 1.5). Rather than create such a QName we could trap this
'error' at parse-time by creating an NCName object (which contains NCName
validation logic) from the attribute value and only create the QName if
there are no NCName errors. If there are NCName errors no QName will be
created and the relevent API method like Service.getName() will return
null. And of course, the null QName error will get reported by
WSDLComponentValidator.
So, I don't think we need to 'fix' Woden to report an error - the error
already gets reported, but I do think we should check that we have a valid
NCName before attempting to use it as the local part in the QName ctor.
Unless anyone thinks differently, I suggest you raise a JIRA on this.
> Surely it should have a signature like this in
> BindingElement:
> public NCName getName();
I agree. The Element API is meant to reflect the WSDL infoset, so
BindingElement.getName() should return an NCName, not a QName. In the
Component API, Binding.getName() will still return a QName as it should.
Other accessor methods will need to change too to reflect this such as
DescriptionElement.getBindingElement(NCName). Another JIRA?
thanks,
John Kaputin
"Jeremy Hughes"
<[EMAIL PROTECTED]
rg> To
Sent by: [email protected]
[EMAIL PROTECTED] cc
om
Subject
Re: QName prefix and localpart
01/06/2006 15:34 handling
Please respond to
[EMAIL PROTECTED]
he.org
On 5/31/06, Graham Turrell <[EMAIL PROTECTED]> wrote:
> <binding name="ns1:BankSOAPBinding">
> ....
> </binding>
The Binding component in the WSDL spec defines the name property as a
QName. The XML representation is defined as an NCName. Which I
interpret to mean that the namespace of the QName is always the
targetNamespace.
It turns out that Woden DOMWSDLParser assumes the name attribute is a
well formed NCName and just passes its value [Attr.getValue()] into
the localpart param of the QName ctor.
So I think we need to fix Woden to report an error at this point.
While looking at this I notice that the Woden Binding interface correctly
has a
public QName getName();
method. However, BindingElement also has a method with this same
signature. Surely it should have a signature like this in
BindingElement:
public NCName getName();
Any one else like to comment?
Cheers,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
