[xml-dev] Managing XML dialects - any good processes?

[Ian Graham <igraham@ic-unix.ic.utoronto.ca>]

I am working with a large financial institution that is just now starting
to use XML as an internal data modeling and messaging tool across several
different applications -- from mainframe on down -- mostly aimed at
internal uses only (i.e., messaging between internal applications). This
has started quite suddenly and is proceding very quickly (some promotion
didn't hurt, I suppose ;-) ). However, I see some potential XML
'management' problems, for which I have proposed some simple control
mechanisms, but I'm wondering three things:

 1) does what I am proposing make sense to others who've already
    been down this road.
 2) has anyone had success with other approaches
 3) is anyone aware of tools that can help manage [i.e., automate]
    this process?

At present I see the following problems:

 * each group is working largely independently, and is thinking of
   XML as an 'internal' issue to their application, whereas in fact
   they must allow for reuse of messages in other application contexts.
 * indepdendent development of different application 'dialects'
   can lead to incompatible semantics and interoprability problems
   when two messages encode similar data using incompatible schemas.
 * lack of XML expertise means that they don't necessarily know the
   best XML 'patterns' to use when developing new tools.

As a first pass at reducing problems, I have urged the groups to talk to
each other ( ;-) ).  This they are doing, to some degree, but practical
time pressures will limit this interaction. I've also suggested (as have
others) that they mine XML 'patterns' from existing standards in their
field (financial services).  Some of the patterns seem pretty lame to me,
but at least they model the business processes in a standard way, which is
the most important thing.

I am also pushing for a centrally managed XML namespace registry, and for
mandating that each group _must_ specify a unique namespace for their
dialect, and in their messages.  In principle we will then store relevant
information at the namespace URI (I've proposed using RDDL to do so), but
for now I'm more concerned with getting the namspace identifiers in there,
so that we can distinguish dialects and 'track' their use.

For documentation I have recommended DTDs and written prose - I've
recommended against schemas for now since (a) they won't be using them to
validate, so they're not needed, (b) i've seen enough oddities (some
described on this list) in first-generation schema processors to think
it's best to wait a half year or so, and then convert the prose/DTD into
an appropriate schema, where relevant/useful.

So, how do those steps sound?

Last, there is some demand to try and find a software 'solution' that will
aid in the central management of dialects (affectionately known here as
tag sets).  I am not familar with anything that does this, although one of
the lead s/w architects here was approached by Innovision
(http://www.innovision.com), who claimed that their product suite supports
this sort of functionality.  I was a bit concerned, however, to find that
Innovision's products don't seem to support the namespace recommendation,
which aside from being a bit odd this long after the spec became a
recommendadtion, would make it hard to integrate their system with
applications that use namespaces.

So, is anyone familar with using Innovision's tools to do this sort of
thing?  Beyond that, is anyone familiar with other toolsets/suites/
"solutions" (hate that word) that would help manage the evolution of
multiple XML dialects?

Thanks in advance --

Ian