The ctor for QName specifies a String argument for local part and the
Javadoc (J2EE 1.4, J2SE 1.5) does not specify any special handling beyond
null and empty string. The NCName class has the appropriate ctor
validation.
John Kaputin
Arthur Ryman
<[EMAIL PROTECTED]
> To
woden-dev@ws.apache.org
01/06/2006 21:22 cc
Subject
Please respond to Re: QName prefix and localpart
[EMAIL PROTECTED] handling
he.org
IMHO, Java classes should enforce semantics and throw exceptions at the
earliest possible point. Therefore the ctor for NCName or QName should fail
if passed an invalid name.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 06/01/2006 03:56:47 PM:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
