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: user@xmlbeans.apache.org
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: <user@xmlbeans.apache.org>
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]

Reply via email to