Castor Generated Classes (XML Marshalling) - XSD Unavailable - xsd

I recently moved to a project where I noticed there have a specific requirement to store some data as XML.
The prior team used Castor generated classes to Marshall and Unmarshall the data.
I have a new requirement now that requires me to add some additional (yet optional) fields to this XML. However I realized the prior team supposedly never checked in the XSD at all and I have no way to reach out to them.
The XSD for sure was large and complex since it is responsible for generating around 50 classes. So writing the XSD again is going to be error prone and also a risk that I might end up creating XMLs now that are in compatible with the old XML.
The other alternative I thought of was using a tool like XML Spy and try to reverse engineer the XSD from the XML, however that sounds a bit difficult too since I will need to reverse engineer 20 odd XMLs to generate XSDs and then merge all these XSDs into one, since the XML had several optional sections. There is still an element of error possible in this approach.
The best option I can think of is reverse engineering the classes to an XSD - however Castor supposedly does not support this feature. So I don't have the means to convert these Castor generated classes back to an XSD! While the classes generated by Castor do have some Castor specific methods, in essence they are Pojos if the Castor specific methods are ignored!
Do we have any suggestions here for getting or generating the XSD from java classes? Do we have any other suggestions to solve the issues I discussed?
Thank you.

Just an update, while I have not achieved 100% of what I was looking for, I was able to successfully reverse engineer the XSD using JAXB's schemagen tool.
Just note that castor generates an XXXDescriptor with each class since that does NOT map to the actual XSD do not pass the XXXDescriptor classes as input to the schemagen tool.
The schemagen tool works with the getter methods and ignores methods like Castor's validate, marshall and unmarshall.
So things look quite hopeful at this point, compared to the situation I was in when I first posted the question.
Thanks.

Related

Does KEY/KEYREF work with JAXB

I have an XSD file declaring lots of classes (using unmarshalling). Upto now, there was one relationship between two of the generated classes, which is modelled by using ID and IDREF. This works perfectly well.
I have to change the app. Now I have two independent relationships and ID/IDREF doesn't work anymore.
I guess, I have to use xs:key/xs:keyref.
But, all I found on JAXB2 suggests, that unmarshalling of xs:key/xs:keyref just validates, but doesn't generate the relationship in Java code.
Is this still true?
Regards, Claus

Is it a good practice to use a converter inside a populator?

Hybris tell us that Converters should use populators and not vice versa because can be critical for performance considerations.
But when I am digging in hybris code you can see populators like DefaultAbstractOrderEntryPopulator, ProductFeatureListPopulator which
are wiring converters.And I have also find Populators using other populators such as ProductPopulator.
I read the following links but I cannot find anything about using a converter inside a populator or populator inside of populators:
Wiki Hybris - Converters and Populators
Wiki Hybris - DTOS best practice
Wiki Hybris 6
so, can we use converters inside populator like Hybris does? and populators inside populators?
I would like to give my point of view to answer this question. One common mistake when working with converters and populators is to confuse them.
Converters creates a DTO and populators filling the DTO.
We have to be very careful when we are going to use a converter inside of a populator and to be completely sure that
we need to do that.
If we have a long chain of populators using converters we can have a performance risk. For instance
C1->P1->C2->P2->C3->P3....
I think the best practise to follow is:
1) Be aware of the converters are already done, and ckeck if we have to add our populator to an existing Converter
(for example using the modifyPopulatorList)
2) If our DTO has another dependency with other DTO
We should ask ourselves if that dependency it is really necessary.I will decide this according to if that second DTO is used in many places
or not.Because if you are the only one who use it maybe you can merge the properties in only one DTO and avoid to have two different converters.
3) Other possibility It is to use differents converter in parallel as we can see in
WIKI HYBRIS - Facades and DTOs
To sum up, the design of our converters and populators is our responsability, and we have to get the best design posible of them to avoid
performance problems.
Basically the way to do it is: never write a concrete converter class and never call a populator directly.
But this is how the product is built for extensibility and frankly you can do whatever you like.

What is the canonical document schema for representing UML?

I want to represent UML models in a serialized document using the most standard conventions available. I am looking for a canonical schema document that explicitly dictates the best way to do this. I suspect that, if such a document exists, then it would be written in either XSD, RDF and OWL. So far, I have only been able to find OMG specification documents and academic papers on the subject. I have found some XSD schemas, but they only apply to a particular aspect of the implementation.
Is there a canonical document schema? Where can I find it? If not, what are the most common representation formats and where can I find their schemas?
Are there any libraries that facilitate the generation of mappings from well-formed documents of this kind to graphical representations (e.g. SVG)? The library would ideally be .NET compatible, but this is not a requirement.
Are you looking for XMI (XML Metadata Interchange)? It's an OMG spec for XML representations of UML models; the current version appears to be 2.4.1, and the spec page links to two XSD schema documents.
In theory, XMI should answer part of your first question. XMI is not, however, without perils. From my own experience trying to achieve exactly the same, I would think that the first thing to do is to understand what others did about it, and how these standard documents would be used. These days I would suggest a system setup that involves IBM RSA and Sparx Enterprise Architect (eval versions available, registration may be required, and I am not affiliated with any of these companies). Build at least one comprehensive UML model which would give you the coverage you need, in one tool, then use the XMI export/import function to move the model between them. See what happens. Take a look at a company such as this (the makers of TOOLBUS, not affiliated with them) and think how XMI should affect their business model, and yet it seems that it doesn't...
I would think that success is achievable, but may prove feasible for a (very) narrow scope - scoping is key here.
As for the second part, I don't think you're going to find it, particularly for .NET.
XMI is the keyword you need. But XMI specifies only the document format. It does specify the document structure or contents. The UML metamodel does this. A library which does both for you is org.eclipse.uml2 - it implements the UML 2.4 metamodel and allows to store and restore it in XMI. IBM RSA uses this library as well. As several other Java Tools do.
I'm not aware of a UML2 implementation in a .NET language.

Auto generate XSD from BPEL? or BPEL from XSD?

So I am new to BPEL, and indeed my XML knowledge is limited (but growing fast as I do this project). I am creating a webservice in BPEL. Now the drag and drop is fine, but what about complex types? I can modify the .xsd file to have them, but do I then need to edit my .wsdl file and .bpel file to match or is there a way to auto generate this to reflect the changes in the .xsd file.
I am using Jdeveloper 10.
Thanks
Not sure about how JDeveloper is dealing with this, but conceptually BPEL only reuses type definitions made in WSDL and/or XSDs that are imported into the BPEL definition. Thus, if you change data types in your schema definitions, the BPEL process with use them accordingly.
To be more concrete, the typical scenario is that you have defined your schema in XSD, import that into your WSDLs and use it to define messages based on your schema. In your BPEL process, you can reference the message types (defined in WSDL) or elements/complexTypes (defined in the XSD).

Formatting XSD scheme for peer review

I designed a data model which is represented by an XSD scheme.
The data model also provides the types that are being used as web service parameters in a WSDL descriptor.
I would like to send the XSD scheme around and ask the people involved to peer review the data model.
What tool or presentation method would you suggest to be used as a basis for peer reviews? The data model should be readable for non-skilled people, at least when it comes to the semantic meanings of the parameters
Edit:
To be more specific: Of course, syntactically, the scheme validates. Actually I'm already working on code which is based on JAXB generated classes. My goal is
to freeze the data model and thus
the input parameters
to make sure
nothing got lost or forgotten from a
semantic (in the meaning of
business-relevant) point of view.
Edit 2
I've been thinking about how it probably would be best to spread a datamodel around. I'm thinking of something like a JavaDoc for XSD schemas. Anyone knows if something like that exists? Basically it would be done with a set of XSLTs, right?
I know the following tools that generate documentation from XML Schema files (XSD):
xs3p
XSLT stylesheet that generates single XHTML from XSD
xsddoc
free / LGPL
mainly XSLT based
JavaDoc like output
see xsddoc examples
xnsdoc
improved commercial version of xsddoc
free for personal/educational use
JavaDoc like output
XSDdoc 2.0
commercial
JavaDoc like output
For small a XML schema, I would probably suggest using the xs3p XSLT stylesheet. For more a complex schema, I suggest using xsddoc.
I recommend using the XSD for something. Specifically, show some actual applications, with examples as real code.
Actual applications are what make a schema interesting. The examples don't have to be big, sophisticated or completely realistic. They just have to compile. Other people will want to copy and paste the code samples.
These examples are the "hello world" of the schema. And they act as a kind of unit test for the schema.
The closest thing to Javadoc for an XML schema that I've seen is running the Javadoc tool on source generated from the schema. This requires two things: 1) That your schema has internal annotation elements documenting it, and that 2) your source generator uses those annotations as Javadoc elements.
The very useful Oxygen XML developer also supports generating documentation, see
http://www.oxygenxml.com/xml_schema_documentation.html
(commercial, but there's a fully functional 30 day trial available)
I'll try it out now, need a simple way to generate a document with all types and available xsd:documentation description as a simple interface description...
** Disclosure : I work for Innovasys, the producer of the documentation tool mentioned below *
You could take a look at Innovasys Document! X. As well as automatically generating a structured and linked page for every element, simple type, complex type, group and attribute group it will also generate linked XSD diagrams (including sequences/choice etc.) and structure tables that include the annotations from your XSDs and make sense of the relationships between the elements in your schemas. The output is template based so you can adapt it to your preferred style and structure. It will build output to web ready html or compiled help files.
Uniquely it also includes a WYSIWYG editor that allows you author additional content to supplement the stuff that's automatically generated and the annotations from the XSD source - so you can provide additional contextual information for your peer review. There is also a Community Extensions feature that allows people viewing the generated output to record comments and feedback and that can be viewed and actioned directly from within Document! X.

Resources