>Actually that code is not completely new, it was simply >commented out by myself for a while because it was breaking >some test cases for Castor generated code.
Yes, sorry, this is the same code that I was referring to previously in connection with Bug 1138. >What thread are you referring to? I don't know who Jean-Pierre >Loeffel is, so you'll have to point me to a specific thread >that you are talking about. > Date: 2003-09-30 12:19:40 Subject: [castor-dev] Marshall and namespace prefix Link (hope it works) : http://marc.theaimsgroup.com/?l=castor-dev&m=106492482318472&w=2 >Castor's bind-xml name attribute is a QName, so you can very easily specify a namespace as such: > ><field name="foo" ..> > <bind-xml name="bar:foo" xmlns:bar="...."/> ></field> As you will see in Jean-Pierre's post, this is what he uses. But, he didn't find a way (me neither) to avoid writing this upon marshalling: marshaller.setNamespaceMapping("invoice", "http://www.abc.com/XSD <http://www.abc.com/XSD> "); Without this, Castor generates the prefix ns1. This is why I thought this approach was a "workaround." I am also aware that there is an attribute called QName-prefix in <bind-xml>, and I (unsuccessfully) tried to use it, but since I didn't see any documentation on it, I might just be wrong about its purpose. I should also mention that this method of making it work is quite different from how it is done for the class's element name binding (and consequently unintuitive). As I worked with these issues today, I found out another strange marshalling behavior. I will demonstrate this through an example. Mapping file: <mapping xmlns:faq="http://example.com/faq";> <class name="com.example.Faq"> <map-to xml="faq" ns-uri="http://example.com/faq"; ns-prefix="faq"/> <field name="sections" type="com.example.FaqSection" collection="set" > <bind-xml name="faq:section"/> </field> </class> <class name="com.ingemark.faq.model.FaqSection" verify-constructable="false"> <map-to xml="foo-bar" ns-uri="http://example.com/foo-bar"; ns-prefix="foo"/> <field name="title" type="java.lang.String" get-method="getTitle" set-method="%1"> <bind-xml name="title" node="attribute"/> </field> </class> </mapping> Notice the <map-to> element for the second class. It defines its own element name, namespace and prefix. When this is used to marshal the Faq class, it produces the following XML: <faq:faq xmlns:faq="http://example.com/faq";> <foo:section title="Section 1" xmlns:foo="http://example.com/faq"/> <foo:section title="Section 2" xmlns:foo="http://example.com/faq"/> </faq:faq> The "section" field is mapped to an element in the namespace specified by the QName "faq:section," but the prefix is used from class's <map-to> element. If the binding element for the "section" field is changed to <bind-xml name="section"/> then it will be bound to the namespace indicated in <map-to>: <faq:faq xmlns:faq="http://example.com/faq";> <foo:section title="Section 1" xmlns:foo="http://example.com/foo-bar"/> <foo:section title="Section 2" xmlns:foo="http://example.com/foo-bar"/> </faq:faq> So the marshaller combines information from class/map-to and field/bind-xml in a quite haphazard way. Yet another complaint is that in the mapping file you have to specify the namespace URI both in the prefix binding (xmlns:faq="...") and in Castor's ns-uri attribute. I see these circumstances as arguments in favor of my proposed solution because it is clean and consistent with the method of namespace binding for the class's element. Alternatively, ns-uri attribute could be dropped and class's namespace binding done through QNames as well, like this: <map-to xml="faq:faq" xmlns:faq="http.example.com/faq" /> >...omitted discussion about wildcards... > >This seems to be a valid concern, please file an enhancement >request for the namespace wildcard support via Bugzilla. Actually, it is about imported namespaces. I did not do any tests with wildcards and I wouldn't know where to start because I don't see what code should SourceGenerator generate to represent a wildcard element, which can have any content (of any complexity). I suppose there is no place for element wildcards in schemas used by SourceGenerator. I noticed that Castor is already aware of imported schemas, it just fails to assign correct namespaces. If you wish, I can file a bug report to Bugzilla about that. Marko ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
