• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Using Java to generate xml from XSD schema

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know there have been several threads about generating xml from XSD schema, but seems nobody actually has a need to do it programmatically.  I feel I actually have a valid use for it.

I am writing software that interfaces with an external application that sends xml data to load into a form (a PDF).   Our service returns the PDF with the loaded xml data, and the user can then edit and submit the form to us.

When the form is submitted to us, we have a process that extracts the xml data in the original load format, and we convert the data to an alternate 'submit' xml format.

A form can also be reloaded with submitted data, in which case we get the submit xml format and convert it back into the original load format, load it into the form and return it back again.

To do this, we maintain a 'skeleton' xml structure of both load and submit formats, and XSLT is used to translate between these formats.

This is working well for us - the skeleton xml allows us to do a copy transform of the destination format,  and fill in the missing parts from the other source format.  One advantage we have is all non-leaf elements correspond to object names from the external application, and we have a mapping between the names, so translating isn't too complex.

However, the skeleton xml are maintained manually, and updating it for data changes is cumbersome.

The next thing we want to do is provide a way to accept an xsd schema for both the load and submit document formats, and generate the skeleton xml automatically.

The documents defined by these schemas have no namespace. They are authored by other developers, not in an automated way.

There is no mixed content allowed. That is, elements can contain elements only, or text only.

The rules for this sample xml are:

  • elements that can contain only text content should not be created in the sample xml
  • all other optional and mandatory elements should be included in the sample xml
  • elements should be created only once even if they can occur multiple times
  • any other nodes such as attributes, comments, processing instruction, etc. should be ommited - the sample xml would be an 'element tree'


  • Are there APIs or tools in Java that can generate such sample xml? I'm looking for pointers where to get started.

    This needs to be done programmatically in a reliable way, as stated earlier, the sample xml is used by other XSLT transformations.


     
    Saloon Keeper
    Posts: 10762
    229
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I believe this is such a rare case that nobody will have written a library that does this for general purposes.

    You will have to write a library that does this for you. Given your constraints, I don't believe it will actually be that difficult, but you'll have to ask yourself: Is it worth the trouble instead of just updating the skeleton template every time you change the XSD (which I imagine won't be very often)?

    If you do go this path, you don't actually have to do this in one go. For instance, your library can support just the XSD tags that your application currently uses, and whenever you find you need more complex processing, you can just add the functionality to your growing library.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 10762
    229
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Just to clarify, I understand that your question boils down to: Given an XSD, automatically generate a simple empty XML template that will pass the XSD's validation.
     
    dave cline
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you

    Just to clarify, I understand that your question boils down to: Given an XSD, automatically generate a simple empty XML template that will pass the XSD's validation.



    Yes, but with the exception that elements containing only text, even if required, would not be generated.  The XSD will always define such elements as 'leaf' elements.

    Given your constraints, I don't believe it will actually be that difficult, but you'll have to ask yourself: Is it worth the trouble instead of just updating the skeleton template every time you change the XSD (which I imagine won't be very often)?



    For the near term, no, we only have a few forms.  But, longer term we are growing to several dozen forms, and each one has their own load and submit formats.  Early on during development, these metadata formats change often.

    I wonder if using a tool, that can generate sample xml, and then in a second step using XSLT to transform the sample xml into the skeleton structure described earlier could work?

    I'm not sure what tools would be suitable though, a google search turns up a couple:

    Sun/Oracle Multi-Schema Validator,
    https://code.google.com/archive/p/jlibs/wikis/XSInstance.wiki






     
    Stephan van Hulst
    Saloon Keeper
    Posts: 10762
    229
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sure, that looks promising. Run your XSD through the tool and see what it outputs. From there you can determine how hard it would be to transform the output to your skeleton.
     
    Cob is sand, clay and sometimes straw. This tiny ad is made of cob:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!