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

[Ronald Bourret <rpbourret@rpbourret.com>]

I haven't written DTDs in a large corporation, but that doesn't stop me
from having opinions:

1) Requiring namespace use. It would be insane not to do this.

2) Using DTDs. A tossup. Yes, schema implementations are newer than DTD
implementations, but schemas provide a number of advantages, most
prominently data types. The idea of starting with DTDs and moving to
schemas is probably a good one, especially if people are new to XML,
since DTDs are much simpler to learn.

3) Talking to each other. A great idea, but very hard to implement due
to politics. Four years ago, the XML community waved their hands at this
question and said, "Industry groups will get together and come up with
standard DTDs." This is just happening now, to the extent it is
happening at all.

4) Documentation. Absolutely required, and always difficult to get
people to do.

-- Ron

Ian Graham wrote:
> 
> 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