new free tool: WSDL Flattener enters alpha stage

I've developed the Xml Schema Flattener and Schema Lightener to solve specific problems around maintaining large libraries of Xml Schemas as well as communicating their practical use for a given setting.

I've always wanted to do the same thing for WSDL files. And in fact, have gotten several requests to do just that. Well, I've been getting enough inquiries recently that I thought I would put some time in on this.

The basic goal is to create a WSDL Flattener just like the Schema Flattener. Develop modular WSDL files and connect them via wsdl:import; which also contains a section with an xsd:schema element. This schema would in turn have xsd:import and/or xsd:include files. Indeed it seems that everyone developes schemas separately from the WSDL. So how about a tool that would take the whole thing and munge it into a single, stand alone WSDL file? Schemas and all. And to do it via XSLT (meaning open technology).

Well, I am getting very close to this. It didn't take long to be able to merge wsdl:imports. But adding in the nested flattening of schemas took a bit longer. I have a draft that seems to work. But I need to do some serious testing before I sent it out.

So stay tuned for this addition to the xmlHelpline Free Tools section.

Detailed feedback on Schema Lightener / Flattener

Been getting more and more interest and feedback on the free Schema Lightener and Flattener combo tool (and I can't resist a link explaining its testing here. I've recently tested with NIEM too).

Here is a note from Kurt Kanaskie, Enterprise Architect at Merck and Company:

In any case, I spent some time with the Flattener and Lightener today, excellent work on your part!!!

The Flattener does exactly what I need it to do for what I've been calling our Production BODs. Since we use extensions via UserArea our delivered BODs need to have access to the entire set of elements in the OAGIS common library since any element may be used in a UserArea extension. Especially if we change the UserArea over time, then I just need to update the UserArea type. I've been doing this manually by placing all of the common developer schemas in a shared folder which is used the BOD and Noun. Effectively I provide the developer Schemas in a simplified folder structure. But now with the Flattener its easier!

Then I went on to the Lightener and I am very impressed. It works great!!! I did notice some situations that are not behaving as I expect. For example if I have SalesOrderReference only on the PurchaseOrderLine it also shows up on the Header and vice versa. If I remove them both, they both go away. [This behavior is by design. The Lightener removes components that are *never* used. It does not handle contextual variation, meaning an element used in one place but not another. In this case, it simply retains the elements. I've worked on a contextual variation version of the Lightener, but have not yet finished it. ]

I even ran it on a custom BOD, SyncActivity which just creates components for Activity and Resource from OAGIS components and fields. It works!!! Even lightens the imported Schemas! I did notice though, a few empty sequences, but still validates just fine. [Yes it may create empty sequences, but as you state this is still valid. If enough folks want the Lightener to remove empty sequences, it can be done.]

Let me know how I can really buy you coffee, this is great work!!! [You can buy me a coffee here.]

Best Regards,

Kurt Kanaskie
EA Solution Architect
Merck & Co., Inc.

TranslatHR free tool

Just launched the TranslatHR project in draft form via a webinar. It attempts to facilitate the migration from HR-XML 2.x standards to the new version 3.0. It uses simple, free XSLT to translate 2.x xml instances to 3.0 instances.

Other proprietary tools can create XSLT from really nice WYSIWYG interfaces. However, the XSLT that results is sometimes opaque and hard to read. So updating, maintaining, and such cannot be done in the XSLT itself.

The solution is to create an easy to read XSLT. Of course some say that is an oxymoron - since XSLT is not easily read inherently - perhaps I should say "easier" to read. And designed to be extensible and maintainable by anyone with an XSLT processor.
Thus the TranslatHR.

webinar: Migrating to HR-XML 3.0

Preparing for a webinar presentation tomorrow. The HR-XML Consortium has recently released its new 3.0 set of standards. This is the first non-backwardly compatible release is many years. It also takes advantage of (by building on top of) OAGIS architecture including its platform implementation of UN/CEFACT core components. Gettings slides and demo in presentable order!

Register here.

Summary:
You've looked at the new 3.0 specification and are considering upgrading. You ask yourself, how can I do this? How much effort is involved in upgrading? Do I have to re-write my entire application? What is the easiest and least expensive way to upgrade? Answering these questions is a critical component of the value decision for implementers. This technical presentation will examine an inexpensive way for implementers to migrate applications from 2.x to 3.0. Participants will be shown (and receive for free) draft XSLT code that demonstrates how a translation can work.

annual charity "walk for hope"

Something for the "other" category.
A number of friends and I are participating in the annual charity Walk for Hope, sponsored by the non-profit Foundation of Hope.

The 21st Annual Thad & Alice Eure Walk for Hope
Sunday October 11, 2009 - Raleigh, NC

http://www.walkforhope.com

We've been doing this charity walk for several years now. Our small group raised about $1,000 last year alone if memory serves. There were over 3,000 walkers/runners last year. It is a huge event.

If you want to sponsor, contact me offline.
And of course "thank you!"

Feedback on Schema Lightener

I've been getting some great feedback on the Xml Schema Lightener tool. As noted, I've tested the tool with various standards. Now I have feedback from others using the tool with OAGIS, HR-XML, SWIFT, NIEM, OTA, ACORD, and proprietary schemas.

Here is a sampling of feedback (names omitted):

"I tried out the XML Schema Lightener. It works great! [...] You have provided a wonderful tool for the XML community. I hope you enjoy the coffee I sent you."

"I did a first test and it seems to work really well. This is just what I have been looking for just to get a XSD-schema that actually tells how the schema is used by my organization. The test I did for now was [...] on a propritary Xml format delivered by a company [...] ERP. "

"I haven’t tested it exhaustively with ISO 20022 schemas, but where I have tried it, it seems to work perfectly – exactly as advertised. For many use cases I am sure it could be very helpful."

"I have already worked with your schema lightener tool and i really liked it.... "

[feedback via my Linkedin profile:] “The schema lightener proposed by Paul is a powerful solution for people who are concerned by reliability and optimization of schemas. The tool responded to our needs at Aeroplan when we had several big schemas to "refresh"...”

[After a new release of the tool, fixing a bug] "The good news is that all of the problem scenarios I encountered before worked with the latest drop."

A sampling of feedback on use cases (names omitted):

"I’ve been thinking of writing just such a program, but came across your site! Very cool!"

"I would love a copy of your tool. I am working with a ridiculously large schema (from ACORD) that I need to subset."

"Your software looks like the solution to my nightmare, to lighten some OTA schemas."

"I would like to 'lighten' the 3000+ page ACORD schema, which is a standard for the Property and Casualty Insurance industry. My company only [works with] two of the dozens of lines of business included in the schema. I would like to simplify the schema to include only those lines of business we support. It looks like your XSL utility might do the job."

"I am working on a project using Oracle’s version of the OAGIS schemas and they have thousands of elements, and we end up using about 50 of them."

"I am working with XML Schema and have been developing subsets by hand. I am very interested in your XML Schema lightener."

"Your product looks interesting – the problem has occurred several times for our customers."

"I think your tool would be useful to some of those organisations who implement our schema for b2b messaging."

New Orleans 2.0 - version management from a different perspective

Had an interesting discussion with some colleagues recently about version management. Versioning is often a long conversation and has many theories / best practices. In order to gain a different perspective, we talked about it using New Orleans as the object to be versioned (not sure exactly how this got started). Using this analogy strips away the technical associations and assumptions that traditionally come up in these conversations.
At any rate, we began with New Orleans 1.0, founded in 1718 according to wikipedia (so it must be true). One can say that ownership is a reason for versioning, so the ceding of the city to Spanish control in 1763 could be considered a "New Orleans 1.1". The city had not physically changed and everything was still as it was. That is to say it was "backwardly compatible". Then another version came in 1801 when it reverted back to France and finally again in 1803 to the U.S. via the Louisiana Purchase. This puts us as New Orleans 1.3. A few thought ownership itself could be a major not a minor version, a "2.0" so to speak, but most though not.
One can also say that events since then were all backwardly compatible. The city never moved or completely burned. Its inhabitants grew but did not fundamentally change. Major improvements would be a good reason for a revision, such as the massive levee system created by the Corp of Engineers. This is the equivalent of adding new functionality while maintaining backward compatibility. Each new revision enabled the city to grow, better deal with problems, or overcome obstacles. Discovering oil is an example of a growth change. Creating the levees for flood control illustrates better problem management. Finally, the installation of railroads overcame problems with transportation of goods. In short, the revisions were "enablers". So the 1.x version of New Orleans created a usable, creative, and culturally robust product.
But there was a problem. The geography and elevation of the city made it vulnerable to hurricanes. A flaw existed in the 1.x. The city tried to fix this vulnerability with a backwardly compatible change, namely the levee system. And indeed this revision seemed to be working. But the fierceness of hurricane Katrina showed that the flaw in New Orleans 1.x still existed and was not adequately fixed.
So what to do? Create a 1.x+1 of the city with even bigger and more massive levees? That seems to be the solution in the works. But yet another revision seems like less of an enabler than a patch for preventing the object from failing. This is certainly analogous in software where patches and revisions are early enablers. But at some point they become band aids meant to retain the original. Plugging a leaky boat to use one colleague's poor analogy.
So we asked each other "should the city be moved to higher ground where it was less vulnerable to hurricanes?" It was agreed that this move would have to be considered non-backwardly compatible. One simply cannot pick up the French Quarter, move it, and expect it to be the same as it was. A geographic move, while fixing the problem, would be a major version. It would be New Orleans 2.0.
But is New Orleans 2.0 still New Orleans? Is the essence of the city inexorably tied to its original major version number? Will it forever have to be 1.x? At what point do you have a new object altogether? We were so used to asking these questions in the context of technology.
While we weren't entirely in agreement, there was a lot that we did see similarly. Raising the levees would be a 1.x+1 and would be a huge patch (not so much an enabler). Moving the city would be a "2.0" and not a "1.0" of a different city. New Orleans could be majorly versioned and stay New Orleans. But should it? We were divided on the policy of patching the levees. Saving the city at all costs was analogous to saying "maintain backward compatibility at all costs". Whereas moving the city could be translated into "don't let backward compatibility prevent you from innovating and creating better solutions".
And that was where it ended. We tended to agree on the definition of major and minor versions. However what "should" be done, or the policy, was not as shared.
I think I've been here before, but starting from a much different origin.