On 6/1/06, John Kaputin <[EMAIL PROTECTED]> wrote:
> 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.
I'm curious as to why NCName operates differently to QName w.r.t
validation in the ctor. If the localpart parm of the QName ctor
contains a colon QName doesn't complain and a (surely) invalid QName
is constructed. The JSE 5 javadoc for QName.valueOf() admits as much:
"This method does not do full validation of the resulting QName. In
particular, the local part is not validated as a NCName as specified
in Namespaces in XML." [1]
I think this model helps parsing - QNames can be constructed which
represent the valid or invalid data in XML. Then the QName is there
for the validator to check semantically later. Perhaps the NCName
should work to the same model instead of validating the input
parameters to the ctor?
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.
I guess I'm suggesting above that we could have an invalid NCName
created in the Element model which leads to an invalid QName in the
component model. However, this is minor compared to having consistency
between the way NCName and QName classes work. I'll open a JIRA.
> 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?
I've reaslised there's a problem here. BindingImpl implements both
Binding and BindingElement interfaces. If we change BindingElement's
getName() method's return type to NCName, BindingImpl won't be able to
implement both interfaces - it can't have both these methods:
NCName getName()
QName getName()
I have a proposal though - howabout splitting BindingImpl into
BindingImpl implements Binding and BindingElementImpl implements
BindingElement. There is then an issue with tying together the two
impl classes. When you create a BindingElementImpl it would contain a
null reference to a BindingImpl. When you add the BindingElementImpl
to a DescriptionElement a BindingImpl will get created, referred to
from the BindingElementImpl and added to the Description.
If a BindingImpl were created first then the opposite will happen when
it is added to a Description - ie a BindingElementImpl created,
referred to from the BindingImpl and added to the DescriptionElement.
Phew. I think I need to write some code - there's probably a gotcha in
there.
By doing all this, whenever you have an instance of a Binding you can
call QName getName(). Whenever you have an instance of a
BindingElement you can call NCName getName().
Like I said ... I need to write a bit of code to make sure I haven't
made a mistake.
[1] http://java.sun.com/webservices/docs/1.5/api/javax/xml/namespace/QName.html
Cheers,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
