The issue I am reporting on has been known for a long time, at least since Bug 1138.
It concerns the XML Schema feature known as "element form." There is also a related term, "attribute form," and everything said here about the former applies to the latter as well. Primarily, XML Schema defines element names belonging to the specified "target namespace." All the top-level (global) element declarations are qualified, that is, the element names they declare are members of the target namespace. For the local element declarations (those inside complex type definitions -- both named and anonymous), there is a choice: they can be either in the target namespace as well (qualified), or in no namespace (unqualified). The usual method of controlling this behavior is through the XML Schema attributes in the root element: <xs:schema elementFormDefault="qualified | unqualified" attributeFormDefault="qualified | unqualified"> Before the Bug 1138 was addressed, there was a hack that produced the behavior correct for the qualified local element form. The bug fix removed the hack, so now the unqualified form is properly treated. Jean-Pierre Loeffel has more recently (30 Sep 2003) brought up this issue again, but this time for the problem opposite to Bug 1138: he needs qualified local elements. His plea seems to have been lost in mailing-list traffic, though. The point is, BOTH the qualified and the unqualified local element form should be treated properly! I will illustrate this on an example of a simple XML Schema definition: (Example schema 1) <xs:schema targetNamespace="http://example.com/issue"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="unqualified"> <xs:element name="issue"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:schema> Notice the Schema attribute elementFormDefault="unqualified". It says explicitly what would otherwise be implied, that the default element form is unqualified. When we run Castor's SourceGenerator on this schema, it produces classes with the following (correct) marshalled format: (Example document 1) <issue id="id1" xmlns="http://example.com/issue";> <description xmlns="">Description</description> </issue> The element name "issue" is qualified, belonging to the namespace http://example.com/issue. The element name "description" is unqualified, not belonging to any namespace. The above XML is exactly equivalent to the following, more clear form: (Example document 2) <ex:issue id="id1" xmlns:ex="http://example.com/issue";> <description>Description</description> </ex:issue> >From this way of writing it is easier to see what is meant by "qualified" and "unqualified" element form. Now, we change the original schema to the following (the only change is in elementFormDefault): (Example schema 2) <xs:schema targetNamespace="http://example.com/issue"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"> ... same as above ... </xs:schema> We run the SourceGenerator once again, and it produces exactly the same classes as before. So, the marshalled document is the Example document 1. But, now the marshalled format is no longer correct because it should have been: (Example document 3) <issue id="id1" xmlns="http://example.com/issue";> <description>Description</description> </issue> That is, the element "description" should also have been in the target namespace. I myself am interested in a solution that will produce the required behavior through the use of the mapping document. I guess the solution involving Java code generation would involve overriding the XMLFieldDescriptor.getNamespaceUri method appropriately. I propose the following additions to the format of the mapping document: 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. 2. add attributes to the <map-to> element: element-form-default, attribute-form-default. 3. add an attribute to the <bind-xml> element: form="qualified | unqualified". Implementing the item 1. alone would help the matter significantly, but would require redundant specification of ns-uri and ns-prefix on every field. The addition of 2. would make it possible to reuse the namespace defined for the top-level element . The addition of 3. would allow the default behavior to be overridden where necessary. Marko Topolnik, M.Sc. University of Zagreb, Croatia ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
