Hi Mark G,
Yes that would generally make sense, I agree!
But the (I guess root) problem is that the framework of very strict market standards around the use of its XML schema and instances actually goes as far as to say that the prefixes must have a specific name. Non compliance to this is to be rejected as though the xml is invalid.
You and I know that bob:someTagName is the same as ben:somTagName (so long as in both instances the tag names reflect the same namespace)… but for whatever reason, ben: might be rejected becuase it’s not bob: in this environment.
So, your next question (or at least, mine would be…) will be “Doesn’t that make it EASIER to declare in hard-code what the prefixes and their values will be?”.
Yep. But it makes it harder to VALIDATE the incomming prefixes are correct!
It’s all academic now though. I’ve written a service that
a) Regex’s the xml string to extract the namespace declarations (prefixed and default) to determine the prefix and the actual namespace it represents.
b) Creates an nsDecls document containing fields named the same as the detected prefixes, with the values mapped from the namespace.
Part b was fun. I was suprised that the nsDecls document requires the VALUE of the prefix to be the NAME of a field… makes it hard to deal with at run time! Just goes to confirm it was never considered anyone would ever need to know the ACTUAL declerations from within source XML and then use these to generate some output (which is probably a reasonable assumption mind you… I’ve obviously found the exception to the rule!).
I do note that I’m not the first person to want this information at run time though; There’s a feature request with webMethods to have the stringToXMLNode service provide nsDecls, and I’ve found a couple of support articles that end with “this is not yet supported… feature due for next release”…
Thanks again to everyone for your help, I really appreciate it (and I really wish for once I was able to help others in return… but I don’t think I’m at that level yet!).
Cheers,
Ben.
#Flow-and-Java-services#Integration-Server-and-ESB#webMethods