Marko,
Which version of Castor did you try this on, I just tried a sample test case and toggled the elementFormDefault from qualified and unqualified and it seems to be working for me. Did you remember to recompile the class-descriptors are generating new sources? --Keith Marko Topolnik wrote: > > 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
