That's right, what you are doing is the recommended way of extracting the text from a mixed content type, for an explanation of why this is so, see my previous post ( "RE: XMLBeans and XHTML" on 10/24 ).
Thanks, Radu -----Original Message----- From: Helmut Ziegler [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 3:09 AM To: [email protected] Subject: Re: SAX, XSLT or XmlBeans Hi Radu, thanks for your comment! I use the XMLBeans approach now. After experimenting with different approaches it seems to be the most suitable. Nevertheless, I have to use XMLCursor in some places. My XSD contains a complexType with the attribute 'mixed="true"'. ---snip--- <xs:element name="o"> <xs:complexType mixed="true"> <xs:all> <xs:element ref="ol" minOccurs="0" maxOccurs="1" /> .... </xs:all> <xs:attribute ref="name"/> .... </xs:complexType> </xs:element> ---snap--- In some places I have to get some text out of a tag. ---snip--- <o name="xy">This is text.</o> ---snap--- Unfortunately scomp doesn't seem to create a method to do that. So I created a cursor for that tag and used the getTextValue()-Method. ---snip--- myText=oElement.newCursor().getTextValue(); ---snap--- I don't know if this is the most suitable way of doing that but it worked. Cheers, Helmut > > Helmut, > If I understand correcly, this is a case of transforming the > "interchange" XML file into the "stored" project XML file. If that's > correct then it does sound like a fit for XSLT. My very brief > experience with XSLT however tells me that unless the two file formats > are very similar, you'll end up doing more work than you would want, > especially if you're fluent in Java and not so much XSLT. > > The XMLBeans approach and XmlCursor approach will both work just fine, > the difference being that using XmlCursor is a little less convenient, > but more performant, so this is the classic tradeoff that you'll have > to consider. The main argument for using the generated XMLBeans > classes is indeed convenience; sometimes you have a lot of time > allotted for the task, sometimes not and then that is real value. > > SAX is going to be the most difficult way of doing it; unless your XML > files are huge or you're going after the last ounce of performance, > it's going to be hard to justify this complexity. > > My 2c, > Radu > > -----Original Message----- > From: Jimmy Zhang [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 12, 2006 12:16 PM > To: [email protected] > Subject: Re: SAX, XSLT or XmlBeans > > The next generation XML parser called VTD-XML http://vtd-xml.sf.net > > ----- Original Message ----- > From: "Helmut Ziegler" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, October 12, 2006 11:02 AM > Subject: SAX, XSLT or XmlBeans > > >> Hi, >> >> we want to interchange data between two programs via XML and I wonder > >> which technology is the most suitable for it. >> >> We have a schema for the interchange file. >> The external program is written in C++. Our's is written in Java. >> >> We store the project files of our programm by using the JavaBean XML >> serialization. >> >> Now we have to import the data of the interchange file in our >> program. >> There are different ways to manage this and maybe someone - who did >> the same in the past or has the master plan - can give me hint. >> >> Three possibilities: >> 1. I use SAX, parse the XML file sequentially and build my object >> structure for the project. >> 2. I use XSLT (e. g. with Saxon) and create a rule that transforms >> the interchange file to my XML file of the project. >> 3. I use XMLBeans. Up to know I just used XMLBeans to read, >> manipulate and write XML files. I like to work with it as it is very >> convenient. >> It seemed to me that XMLBeans could also be helpful for my >> interchange task. XMLCursor or XQuery are the concepts which caught >> my attention. >> Do you think that XMLBeans can bring me advantages? And which concept > >> would you suggest? >> >> Cheers, >> Helmut >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> 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] > > ______________________________________________________________________ > _ > Notice: This email message, together with any attachments, may > contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, copyrighted > and/or > legally privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not the > intended recipient, and have received this message in error, please > immediately return this by email and then delete it. > > --------------------------------------------------------------------- > 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] _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
