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

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

I honestly thought this would be a hotter topic. But then, when you're
competing with the evil empire, what can you do?

On Fri, 26 Oct 2001, Ronald Bourret wrote:

> 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.

Yes, my thoughts exactly.   I have been trying to drill in the idea that
the namespace mechanism identifies dialect variants ... but it's a slow
slog.

> 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.

Yeah, that's more or less what I thought too.

> 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.

I am trying to act as a bridge here, moving between the groups and passing
ideas back and forth. Plus some of the lead architects are encouraging
discussion, which also helps. But you're right -- people would really
prefer to punt the problem to someone else, and just follow.

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

Yes - perhaps the most difficult part of this whole exercise :-(

Thanks for your comments --

Ian
 
> -- 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
>