|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Managing XML dialects - any good processes?
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 >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








