On Wednesday 13 October 2010 7:58:08 am Benson Margulies wrote:
> 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. el.setName(mpi.getName().getLocalPart());
>
>
> 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
> doing.
I'm not claiming the old code was correct either. :-)
I THINK this should get the concrete name of the part and if it's namespace
qualified, check the namespace and grab the correct schema and such. If in a
different namespace, setup the ref. Definitely a little more involved.
Dan
>
> On Tue, Oct 12, 2010 at 10:23 PM, Daniel Kulp <[email protected]> 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
> > [email protected]
> > http://dankulp.com/blog
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
