cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: XmlSchema, error checking, RFSB, hmm?
Date Wed, 13 Oct 2010 11:58:08 GMT
We're in createWrappedMessageSchema. here's what I have today ...

 for (MessagePartInfo mpi : unwrappedMessage.getMessageParts()) {
            el = new XmlSchemaElement(schema, false);
            // We hope that we can't have parts that differe only in namespace.

The last line used to be ...

        XmlSchemaUtils.setElementQName(el, wrapperName);

That in turn called XmlSchemaElement.setQName, which put whatever you
asked into a QName in the element. And then serialization ignored it.
So the old code was doing, in effect, exactly what the new code is

On Tue, Oct 12, 2010 at 10:23 PM, Daniel Kulp <> wrote:
> On Tuesday 12 October 2010 7:26:49 pm Benson Margulies wrote:
>> Line 1250 of RFSB sets an element's qname to a message part qname.
> I think your RFSB has mods.  Line 1250 doesn't line up with anything useful.
>> The thing is, in the situation at hand, that message part lives in a
>> different namespace than the schema of the element. And, so far as
>> I've understood it, all the elements of schema 'x' have to live in the
>> namespace of schema 'x'. The name of an element is an NCName, not a
>> qname. XmlSchema 2.0 still has an API to set a qname but checks the
>> namespace for sensibility. I am inclined to eliminate this, and make
>> it so that the only setter for names of these things takes strings.
> If it's a top level element, then yes, it must match the namespace.  However,
> I think you are in the method that creates the wrapper types, right?  In that
> case, it's a child element of a sequence.  In THAT case, it can be a different
> namespace, sort of.  It would be a ref to an element off in that namespace.
> Does that help explain it?
> Dan
>> When I do that, what do I do with RFSB? Just pull out the local part
>> of the mpi name and hope for a lack of collisions?
> --
> Daniel Kulp

View raw message