I am currently working on an application that performs the task of importing or exporting some entities. The file format being used for the same is XML. JAXB is being used for XML binding.
The problem is present XSD that defines the structure of entities has no provision for versioning. How do I get started with defining versioned XSD and subsequently XML instance documents provided JAXB lies as the underlying binding framework ?
I have read that there are three possible ways of introducing versions in XSD.
1) Change the internal schema version attribute
2) Create a attribute like schemaVersion on the root element
3) Change the schema's target namespace.
Which one best suits the usecase mentioned below?
Use case: The changes made to the XSD in the next version may invalidate the existing elements. Although the schema itself may not be backward compatible but the application needs to provides support for handling all versions of schema.
XML is designed to facilitate change and flexibility in document structures. Unfortunately, JAXB isn't. The very act of compiling knowledge of document structure into your Java source code makes change to the document structure a lot more difficult.
If structural change is part of your agenda, I think you should seriously consider not using JAXB: technologies like XQuery and XSLT are much better suited to this scenario.
Related
I am working on a project that requires the validation of many XML files against their XSD, the trouble I am having is that many of the XSD files depend on others XSDs, making the usual validation kind of troublesome, is there an elegant way to resolve this issue?
I would prefer if possible to work with those files in memory, the files are not in a concise directory structure that conforms with their importation paths.
Just to note I am working with the Java language.
Assuming here that you work with JAXP, so that you can setSchema() on either SAXParserFactory or `DocumentBuilderFactory.
One solution I was part of, was to read all XSD sources into an aggregated Schema object using SchemaFactory.newSchema(Source[] schemas). This aggregated Schema was then able to validate any XML document that referenced any "top" schema; all imported schemas had to be part of the aggregated schema. As I remember it, it was necessary to order the Source array by dependency, so that if Schema A imported Schema B, Schema B had to occur befor Schema A in the array.
Also, as I recall, <include> didn't work very well with this mechanism.
Another solution would be to set an LSResourceResolver on the ShemaFactory. You would have to implement your own LSResourceresolver that serves byte- or character streams based on the input to the resolver. I haven't personally used or researched this solution.
The first solution has of course the benefit that schema parsing and processing can be done once and reused for all validations that follows; something that will probably be difficult to achieve with the second option.
Another thing to keep in mind (depending on your context): It is a good design choice to control the whole "resolving" process (i.e. control how the parsers get access to external resources), from a performance as well as a security perspective.
I have an application that receives an XML message and then parses it to perform further processing.In order to have this working in my application, after receiving the XML string, I call the JAXB marshaller to marshal it in to java POJOs and the processing takes from here after.
This thing works well till the time I have one version of XML.
Problem
But the problem comes when there are more than one versions of the same XSD. And my application has to deal with both version of messages. Clients to my application may send a old version xml or they may send a latest version XML.
For JAXB I have to convert the XSD into java pojos using JAVA XJC tool, and the problem arises when I convert the latest version of XSD it has the same class names as the previous version, but internal fields and hierarchy of the class is different. this causes problems even if i put the XJC outputs in different jars for each version.
Expected Solution
This change in version is expected to happen every 6 months and I have to make my system able to read the newer version XMLs also alongwith the old versions.
I want to know how to manage this XML processing in JAVA with JAXB or some other framework.
Shall I use SAX Parser? I have read that its not that efficient as compared to JAXB. And after working on SAX parser for last few days, i found out that it can be error prone as it involves looking for each element and getting values out of it and putting it into a java structure of our own and that is a lot of effort as compared to JAXB.
*
Question
Is there any simple solution similar like JAXB ?
*
Temporary Solution Used
I have used a temporary solution, with which i am not happy as a good solution. What I did is, I created a seperate jar for each XSD version using XJC tool. And created different packages ion each jar e.g.
1. Pojos for version 1.2 are in a jar with base package com.cgs.v_12
2. Pojos for version 2.0 are in a different jar with base package com.cgs.v_20
i have added both as a maven dependancy to my system and using them for processing different versions.
For JAXB/ any other solution that maps between XSD -> POJOs, this will be a 1-1 mapping, especially if the POJOs are generated.
Do you have to
(1) map the entire XML to POJO, or
(2) a subset of that XML to a static/ fixed POJO model?
If (1), since the changes in the subsequent versions cannot be anticipated, I believe the solution for the above will be use a strategy pattern to select the correct JAXB artifacts based on the version
If (2), you can explore using XPATH, defining XPATH mappings per version.
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.
I have been looking at ways to parse XML Schema files for metadata of types defined in those files and get other information, and build the type hierarchy to be shown to the user.
I found a number of candidates:
Apache WS Commons XMLSchema API
Apache Xerces XML Schema API
XSOM
XMLBeans
XMLSchema API and Xerces XML Schema API seem the two best suited.
While XMLSchema API was easier to use, it is not as well documented, and Xerces seems to be the one with much more support. However, I have been unable to locate any resources which might help me get started with the Xerces XML Schema API, except their FAQ's which have proved to be highly inadequate.
So my question is twofold - Which is the better choice for parsing and querying Schema files, and there any resources for these two to get started quickly?
take a look at Xstream, it's a good instrument for serialization, but you also can use it for parsing. Here is two minute tutorial.
Another option you might consider is Saxon's SCM format, which is an XML representation of the schema component model. Both SCM and XSOM are closely based on the schema component model defined in the W3C specs, and rely heavily on the user understanding that model; they don't repeat the documentation of the component model in the API definitions.
I have a xsd that in turn uses/imports a set of xsds.
I would like to programtically generate sample xml from the xsd. The xml must contain all elements and attributes populated with example data based on data type.
How can I do this using eclipse api classes?
Also are there any other tools that accomplish this task and can be evoked in a java program or a batch file?
Any pointers to examples/documentation/api is highly appreciated.
Thanks in advance.
if I am reading your question correctly, I believe what you are trying to do is programmatically generate (i.e. using Java) XML documents based on an XML Schema Document (which may in turn import other supporting XSD's).
You may wish to have a look at Oracle/Sun's JAXB (Java Architecture for Xml Binding) which you can find more info about here:
http://jaxb.java.net/
JAXB works with J2SE-SDK and/or IDEs - such as Netbeans or Eclipse, and permits you to unmarshall (read XML documents into mapped Java Objects) or marshall (write Java objects as XML documents) as required. Standard mappings (known as binding declarations) are provided based on valid XML Schema provided to JAXB. You can also provide binding declarations through custom annotations directly within your XML Schema files or by using external JAXB declarations.
Another alternative (similar to JAXB) is Apache's XML-Beans.
Hope this helps!