>Which version of Castor did you try this on...? >Did you remember to recompile the class-descriptors are >generating new sources?
I am using the latest CVS bits through Eclipse and I do a complete rebuild after regenerating sources. Anyway, I see that as of today there is a new revision of XMLFieldDescriptor (1.9) which seems to address the issue (there is a new field, _useParentClassNamespace and the code for getNameSpaceURI() is completely new). I tested with this new revision and the discussed behavior (default form) is now correct for both elements and attributes. The behavior is also correct for explicit element form (see below), but it is incorrect for explicit attribute form (explicit form specification is ignored). The behavior is also incorrect for elements/attributes imported from another schema (they are rendered as unqualified). I realize that my previous post did not make it obvious what is my primary issue: I personally do not need the SourceGenerator approach. I have my own Java classes and want to marshal them using a custom mapping. This is exactly what Jean-Pierre Loeffel has tried to bring to attention. My view is that any serious Java-to-XML binding technology has to provide a way to explicitly state the namespace URI of each element and attribute independently. Currently, this can be specified in Castor only for the element that the class as a whole is bound to. In other words, it can be specified only for the root element of a marshalled document. Jean-Pierre seems to have made a thorough effort to have his requirement met in whatever way possible and came up with a workaround that specifies element namespaces "behind Castor's back." His problem (as well as Jean-Pierre himself :) cries for a proper treatment within Castor. The most important requirement would be met by implementing Item 1. from my previous post: > 1. add to <bind-xml> the same faculty that exists in <map-to>, namely > the ns-uri and ns-prefix attributes. This will make it possible to > specify the qualified name to be bound to for each field separately. XML Schema allows elements/attributes from arbitrary namespaces either through the use of wildcards, or through importing other schemas and declaring references to elements defined therein. Here is an example: (Example schema 3) <!-- this is the schema to be imported --> <xs:schema targetNamespace="http://example.com/description"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:element name="description" type="xs:string"/> <xs:attribute name="id" type="xs:string"/> </xs:schema> <!-- this schema imports the one above --> <xs:schema targetNamespace="http://example.com/issue"; xmlns:dsc="http://example.com/description"; xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:import namespace="http://example.com/description"; schemaLocation="(URI of the above schema)" /> <xs:element name="issue"> <xs:complexType> <xs:sequence> <xs:element ref="dsc:description"/> </xs:sequence> <xs:attribute ref="dsc:id"/> </xs:complexType> </xs:element> </xs:schema> A valid instance document would look like this: <issue xmlns="http://example.com/issue"; xmlns:dsc="http://example.com/description"; dsc:id="id1"> <dsc:description>Description of issue</dsc:description> </issue> (BTW, SourceGenerator fails to produce this document, making the id and description unqualified). After Item 1. is in place, Item 2. can eliminate redundancy in the two most frequent cases in practice -- subelements in the same namespace as the root, or in no namespace (the qualified/unqualified form default). In the end, Item 3. would allow the default behavior to be overridden. This is what XML Schema provides, too, as in the following example: (Example schema 4) <xs:schema targetNamespace="http://example.com/issue"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="issue"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string" form="unqualified" /> </xs:sequence> <xs:attribute name="id" type="xs:string" form="qualified" /> </xs:complexType> </xs:element> </xs:schema> Notice the attribute "form" in the definitions of the "description" element and the "id" attribute. Marko ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
