Hi Frank I can answer your first question and part of your second, but for the precise way in which XmlBeans deals with e.g. <xml-fragment> stuff I'll have to defer to someone else.
This link may help - http://xmlbeans.apache.org/docs/2.0.0/guide/conJavaTypesGeneratedFromUse rDerived.html. In short, in a schema, global elements, global attributes and global types (to name but 3) can have the same name but need to be regarded as being in different "symbol spaces" (see section 2.5 of the XML Schema Spec Part 1 - http://www.w3.org/TR/xmlschema-1/#concepts-nameSymbolSpaces). To distinguish these in the generated Java classes we first translate the name of the schema element/attribute/type to some suitable Java name and then append, respectively, "Document", "Attribute" or nothing. (Local elements/attributes/types can be anonymous in the schema and internally we generate classes for these too with generated names). So for you HeaderDocument.java corresponds to the global element called "header" and VdxHeaderTyp.java corresponds to the global type vdx_header_typ. My guess is that the fragments you are passing in look something like this: <header> ... </header> In that case the XML does correspond to an element, and not to a type - hence the result below is not unexpected. But, as I say, not quite sure how the <xml-fragment> ... </xml-fragment> stuff comes into this. It may be that you could use that to wrap your text and then interpret it as a type instead. Not sure. Cheers, Lawrence > -----Original Message----- > From: Weiler, Frank (KBV) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 01, 2005 11:01 PM > To: [email protected] > Subject: under which circumstances schema compiler creates a Document > class ? > > Hello ! > > I would like to know, for which XML Schema constructs the schema compiler > creates a Document class for a element or type defined in the schema ? > > I have a complex XML schema, which constists of multiple xsd-files, the > schema makes extensive use of namespaces and type inheritance (mostly > types are derived by restriction). > In my application I have to parse xml fragments, and if I try to parse the > fragment with the appropriate type class, the child elements are not set. > If I use the appropriate Document class, all works fine. But there is no > Document class for all schema types or elements. > > Example (schema fragment only): > <xs:element name="header" type="vdx_header_typ"/> > <xs:complexType name="vdx_header_typ"> > <xs:complexContent> > <xs:restriction base="ehd_header_typ"> > <xs:sequence> > <xs:element ref="id"/> > <xs:element name="document_type_cd" > type="vdx_document_type_cd_typ"/> > <xs:element ref="service_tmr"/> > <xs:element name="origination_dttm" > type="origination_dttm_typ"/> > <xs:element name="provider" type="provider_typ" > maxOccurs="unbounded"/> > <xs:element name="interface" > type="vdx_interface_typ"/> > </xs:sequence> > </xs:restriction> > </xs:complexContent> > </xs:complexType> > > The schema compiler creates two classes: HeaderDocument.java and > VdxHeaderTyp.java > > A call to > VdxHeaderTyp head = VdxHeaderTyp.Factory.parse(xmltext); > let all childs unset (null), f.e. > head.getId() returns null. > > A call to > HeaderDocument head = HeaderDocument.Factory.parse(xmltext) > works and I can get the id child with head.getId() > > So, what's the problem ? > Regards, Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
