Rename global entities in an XML Schema

mphare · April 14th, 2010, 03:10 PM

Please, please, please tell me I'm over thinking this.

I'm using OxygenXML 11.2 which uses Saxon PE, HE, or EE for transformations.

I have a set of schemas to define the structure of some XML I'm developing. There are 3 schemas in the set, one is considered the 'base' schema and it imports the next, which in turn imports the last. Each schema has it's own namespace definition. I tend to write my schemas using global entities (elements, attributes, types, groups) and access them through references.

The problem I have is a customer has come along and want to generate Java code from the schemas using something called Castor. I don't know much about Castor, except that it generates Java classes based on global entities defined in the schema.
Castor apparently does not understand namespaces very well and some of the element names I've chosen are already in use by the customer in other XML areas (elements like 'table', and types like 'alpha-numeric') which is why I used namespaces in the first place.

So the customer wants me to rename all my elements to have a unique name. I don't really want to do this as it would affect all my XSLT code, XML files and schemas. So I told them I would use a script to generate custom schemas for them from my schemas and prefix all global entities with a string of their choosing (they chose 'nms_' as they are a network management system) and deliver these schemas to them to use with Castor.

So I did pretty well with renaming elements using a basic recursive 'copy' template as laid out in the XSLT 2.0 3rd edition by Mr. Kay. I've got a few templates to override the straight copy so I can insert the new element names where needed. I leave all non-global element names alone and only change the global names and the references to them.

I suspect attributes and groups will be just as easy.

It starts getting tricky with the types. To do these I need to locate the global types, then search through the sheet to find anything that is referencing it and change the names.

I also need to know if a type is referencing a definition in another namespace and deal with that correctly. Not impossible, but it sounds like a lot of code to me.

As I said, I hope I'm over thinking this and there is really a simpler way to do this.

Please?

Thanks,

Michael Hare

mhkay · April 14th, 2010, 03:35 PM

I remember looking at Castor a few years ago and noticing that it didn't do namespaces very well. Your client might be better off with a better Java data binding tool - there are quite a few to choose from. (I don't expect they can be persuaded to drop the idea of data binding technology entirely.)

Transforming XSD schema documents isn't straightforward, as you have observed; though it's easier if you only have to deal with three specific schema documents, rather than anything that anyone chooses to write. For example, you might not have to deal with all combinations of elementFormDefault and attributeFormDefault, not to mention the "form" attribute which I'm not sure I've ever seen in a real life schema.

One solution might be to use Saxon to export the schema into an SCM file, which collects all the schema components into one place and represents them in a systematic way, making it more amenable to processing (it's still XML). Unfortunately though there's no reverse transformation from SCM back to XSD.

But actually, I'm not sure why the types are causing you greater problems than any other components. I can't see why references to types are more difficult than, say, references to attribute groups or references to element declarations. I would have expected exactly the same renaming logic to apply to all components and component references.

mphare · April 14th, 2010, 05:05 PM

Thanks, Michael.

I have another group consuming the schemas for Java class data binding, I believe they use XMLBeans and they do not have a problem with the namespaces. We tried to get the other group to switch, but they have Castor too ingrained in their process to switch at this point.

You may be right. Type may be no more complex than the other entities. I may just need to spend some more time with it.

Thanks again!