We Keep Coding

XSD for testdata generation

I'm trying to generate flat file for test data using JAVA. Flat file has own mapping document which describes all fields of each line.
I was suggested to use XSD for mapping and I did some research on XSD. As I understood that XSD is for only validation of XML. In this case I have to randomly generate XML file based on XSD and convert it to txt or other format. Because as an output I need flat file, not XML.
It seems like using XSD i'm adding extra steps in creating the file as first create XML, validate with XSD and convert it expected format.
What would be your recommendation in my situation for following the mapping document?
Thanks in advance.

I have seen your kind of setup before. The reasons may be different than your particular scenario, but nonetheless it made sense. One thing to consider has to do with the skills and tools people have available and so whatever makes the job done quick and well, goes.
You seem to describe an offset based, "flat" data structure. In my case, people used COBOL copybooks which are very good at describing this. IBM Rational Developer had a built-in wizard which allows the creation of Java Data Bindings from a COBOL copybook. This is to say that within a minute one gets a Java class which can create a record for your flat file in no time (it comes with all the logic required to do the padding, etc.)
To get the data generated, there are tools capable of generating XML files which cover all constraints defined by an XSD (e.g. alternate content i.e. xsd:choice, enumerated values, etc.) Now, assuming you have a proper XSD describing your logical model of your flat file, one can get 10s, 100s, even 100K XML generated from an XSD spec. It takes a click, plus the time spent by the tool to create those files.
Next, to get the XML files in your generated Java class, and so avoid going through XSLT or whatever (many shops don't have the skills) it may be as simple as writing Java mapping code between a JAXB generated class and the one created above, or if matching is possible, simply annotate the generated class to support JAXB unmarshalling. This last step may take longer to code, but it would be trivial code any Java developer would know how to do it.
This could possibly give you a view into why someone may have recommended Java and XSD for this task. XSD is a modeling language with built in support for constraints, which may prove helpful in generating test data through combinatorial techniques.

Java XML to EDI design

I have a requirement to convert XML to EDI. I have searched a lot for open source free libraries which full fill my need, but could not find any.
So I decided to write my own logic.
Below are my requirements for an application I am going to execute.
Input of the application is: XML data
Output of the application is: EDI (Electronic Data Interchange) representation of the XML data.
I have to apply some business rules on XML data and generate the EDI representation.
Here is my design for the requirement:
The Java POJOs, here onwards these are Source POJOs, to represent the xml data. To load xml data into Source POJOs, I am using JAXB.
The Java POJOs, here onwards these are Target POJOs, to represent the EDI model.
A Java class, here onwards it is XmlToEDIBuilder, to code the business rules
Finally I am using FreeMarker Template to get the desired EDI structure out of Target POJOs.
Is my design looks good? Any suggestions would really help me.

Recently I had a project involving edifact parsing and generation.
I used http://www.smooks.org/ framework for that purpose.
Using the framework mentioned above your application logic steps might be the following:
parse XML to POJO
use precompiled smooks components and your POJO to build your desired edifact version
Smooks components could be extended in case some custom and/or client specific edifact format needed.
Here is the usage example to get you started: https://github.com/lunatech-labs/smooks-examples/blob/master/edifact-in-code-manipulation/src/main/java/example/Main.java

CRUD on XML using Java

I am developing a java application and i am using XML to store the settings and other data in the application.I have read about Java preferences manager API but i felt storing in XML is more convenient in my application.I started usng JAXB first but then i dint find any tutorials to modify the XML once it is created.My application involves storing the Email account details of the users.As the user adds his accounts dynamically , i need to add them to XML as well.So i dint find JAXB convenient(or rather i dint find any tutorials to update or modify the XML ).The only other option i found was DOM parser here http://docs.oracle.com/javase/tutorial/jaxp/dom/readingXML.html .But i feel it is too complicated for such a simple application.speed , memory etc doesnt matter to me.Are there any other alternatives to do this?

This can be a good (java-oriented) solution. Besides being Berkeley DB enables the development of custom data management solutions, without the overhead traditionally associated with such custom projects. yet based on XML files. It's has a very complete documentation for integration with Java lang.

With JAXB you can:
Unmarshal the XML into Java objects.
Manipulate the Java objects to modify the XML.
Marshal the objects producing a new XML document which you can use to replace the original XML.
Or:
Parse the XML into a DOM
Unmarshal the XML using a JAXB Binder
Modify the object
Use the Binder to apply the changes back to the DOM.
Write out the DOM replacing the original XML

I like to point you to XMLBeam (Disclosure: I'm affiliated with that project). This library is ideal to store configuration values in XML and while the application grows maintain the XML format without changing your Java API.
This is how IO operations look like:
Projection projection = projector.io().file(file).read(Projection.class);
projector.io().file(file).write(projection);
You get one liner IO handling and static typed access to the XML content. A pattern for configuration data would be to include a default value template in your JAR, read this if no config file was found on disk and write it back to disk on config changes. But of course you can also create documents from scratch (described in tutorials).

XSD schema changes, XSLT and backwards compatibility

this is more of a high level question about using jaxb and xslt, as I try to gain more of an understanding of what I need to do, and what I need to learn more about.
I have inherited an application that has Java class files generated from an xsd schema (using jaxb), does some stuff, then writes one of these objects to a serialized 'save file'.
I currently need to make changes to the xsd, which of course will mean some of my originally generated classes will be updated. However, I still need to be able to load the old serialized saved files for backwards compatibility - does this mean I need to maintain a copy of the current xsd, and all generated class files in order to load the old serialized save files? Does anyone have a suggested way I can do this, if I must be able to load the old files?
For all future version of the xsd, I intend to output saved files to xml, and use xslt to transform the file before unmarshalling the xml, which I think will work, as mentioned in this thread How should I manage different incompatible formts of Xml based documents. Doesn't help me with the older serialized files though - any ideas?
Thanks.

Probably the main drawback of JAXB, and of data binding in general, is that it makes schema evolution very cumbersome. XML is a technology where people expect to change and extend the schema/data model frequently, whereas in Java it is hard-coded and hard to change. Use of XML-oriented languages like XSLT and XQuery is a big advantage in such situations.
Saving persistent data in the form of serialized Java objects seems completely perverse to me. Before you move to your new schema format, convert it all back to XML. The whole point of XML is that the data is then in a format that is far more durable, and not dependent on the continued existence of the software that created it.

Felxibility of data import/export feature using XML-binding

I am going to develop a database import/export feature in a Java EE application.
I plan to use XML-binding solution to convert between Java object and XML file which is import/export file.
Import feature: unmarshal the XML file to Java object in memory representation, then use JDBC to update the database.
Export feature: inverse the import process. retrieve the database to Java object and marshal the object to XML.
I think it can work fine, but it's not flexible enough. Because the XSD of XML is pre-defined, it's impossible to change XML schema and Java object definition at runtime. Say it's dynamic binding. Even I want the feature supports other file formats (You could forget it, if the format is too far at this stage).
What is your advice about the feature? Thanks!

I don't know whether this is correct answer, but if in any case it is helpful:
I have used Spring, Hibernate, JAXB where you can annotate your database entity class and its element with jaxb annotation and you are not required to write any xml schema files. In spring you can use jaxb Marshaller.
I think it should be possible in pure jaxb also, so u can look into jaxb annotation.

I think it can work fine, but it's not
flexible enough. Because the XSD of
XML is pre-defined, it's impossible to
change XML schema and Java object
definition at runtime
If you think it isn't flexible enough, go with a data interchange format which relieves you from all these fixed schema definitions (I know even JSON has a schema specification but you get the point). Is using JSON acceptable?
I would go as far to argue that if "importing to database" and "exporting from database" is the only requirement, you need not even create Java objects for this. Simply pass in a JSON string which contains the schema which would then be processed by a JSON processor which interfaces directly with your DAO layer. Similarly with the data read from the database. The downside is that "date" support in JSON is spotty at best.
Come to think of it, it need not be JSON. You can take a look at other data serialization formats like Apache Avro. But then again, if XML is your requirement which can't be changed, you can get around the "flexibility limitation" by not using a schema at all.
After all, XML is like violence. If it doesn't solve your problem, you're not using enough of it. :-)