Hello ! Thank You, Lawrence.
The original problem was, that in my schema there was no global element <header>, so I had to parse it with VdxHeaderTyp class, with no success. Parsing the parent element of header was impossible, because it was the root element, and the xml-file is over 1 Gigabyte in size. So I changed the local element <header> to a global element, and the HeaderDocument-class was generated, parsing works fine. Such a luck, that my organization is the owner of the schema itself. Regards, Frank > -----Ursprüngliche Nachricht----- > Von: Lawrence Jones [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 2. Juni 2005 18:09 > An: user@xmlbeans.apache.org > Betreff: RE: under which circumstances schema compiler creates a > Document class ? > > > 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/conJavaTypesGenera > tedFromUse > 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: user@xmlbeans.apache.org > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
