[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Managing XML dialects - any good processes?
- From: Ian Graham <email@example.com>
- To: Ronald Bourret <firstname.lastname@example.org>
- Date: Fri, 26 Oct 2001 21:22:56 -0400 (EDT)
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
> 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 --
> -- 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