ws-woden-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kaputin <>
Subject Changing the handling of qnames at parse-time
Date Mon, 10 Oct 2005 14:36:52 GMT
Lawrence, et. al.,
some thoughts on handling qnames in Woden ...

The xxxElement interfaces in org.apache.woden.wsdl20.xml use
javax.xml.namespace.QName to represent WSDL attributes of type xs:QName or
xs:NCName (where the name is the local part of a qname) and QName[] for
attributes containing a list of xs:QName.  These QName objects or QName
arrays are created at parse-time by the Reader.

For example, InterfaceElement uses QName for the 'name' attribute of
<interface> and QName[] for the 'extends' attribute  - i.e. a list of
qnames of extended interfaces.  (note, the
org.apache.woden.wsdl20.Interface component also uses QName for the 'name'
property but it uses Interface[] for the 'extended interfaces' property).

I based this approach on wsdl4j.  However, in wsdl4j errors are reported by
the Reader as they are encountered during parsing, so if there's a problem
creating a QName object we can tell why.

In Woden, with validation turned on, our approach is to parse the entire
wsdl, even if it's incomplete or has errors, then use the validator
component to check the model and report all errors.  If there is a problem
with a qname attribute at parsing time, e.g. the prefix cannot be resolved
to a namespace declaration, then a QName object will not be created to
represent that attribute. I'm concerned that at validation time, the cause
for an error such as this will not be available to the validator - so the
validator can tell a QName property is missing from the WSDL component
model, but maybe can't tell why when it needs to report the error.

I'm thinking about modifying the xxxElement interfaces to use String and
String[] instead of QName and QName[] and change the Reader to just store
the qname string from a WSDL attribute, instead of converting it to a QName
object at parse-time.  The QName object still gets created at some point
for the component model interfaces, but now the validator also has access
to the original qname string for diagnostic error reporting if necessary.


org.apache.woden.wsdl20.Interface will remain as-is with:
    QName getName();
    Interface[] getExtendedInterfaces[];

org.apache.woden.wsdl20.xml.InterfaceElement will change from:
    QName getName();
    QName[] getExtendsQNames();
    String getNameAttr();
    String[] getExtendsAttr();

Any thoughts on this?

A related, but separate issue is whether to use interface inheritance to
facilitate access to both sets of properties by the validator (e.g.
InterfaceElement extends Interface and InterfaceImpl implements
InterfaceElement). Through a suitable method on the Reader or elsewhere, a
read-only user application could still just see the abstract component
model, without being exposed to the xxxElement interfaces.

John Kaputin

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message