Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Sat, 04 Jan 2003 12:03:50 -0500, Roger L. Costello <costello@m...> wrote: > > Instead, define precisely one, unambiguous "interchange standard". This > becomes the "lingua franca" interchange format. Sigh. The eternal optimism of nerds ;-) that human factors can somehow be assumed away. See http://www.sys-con.com/xml/articleprint.cfm?id=314 for Sean McGrath's take on this: "My contention is that the failed industry-standard schema initiatives of the past did not fail for technical reasons; they failed for human reasons. There is a rich lore of experience here that the new wave of XML schema designers could do worse than mine for valuable insights. Those that don't learn from the mistakes of the past truly are doomed to repeat them. Apart from paying due regard to history, I think XML schema design needs to take a leaf out of the extreme programming book. Start with the customer (human) , do the smallest thing than can possibly work, and start using it. Never lose sight of the human creating the XML content or the human writing software to process the content." > > 1. You should never interchange data that may be calculated. Interchange > using the "fundamental data", from which calculations may be > done. Seems like a useful heuristic, but not a Thou Shalt Not ... Ya gotta consider the processing capabilities of the devices producing and consuming the data, frequency with which data are interchanged, the bandwidth available ... I'm becoming a bit of an Extreme Programming advocate in my dotage -- listen to what the customer wants and do the minimum that can achieve it before you worry too much about large scale abstractions and grand principles. > > 2. The more different ways data can be used, the higher the value of the > data, the less application-specific it is, and the more suitable it is > for data interchange. Sure, but again see the XP people's rants on this subject: a lot more projects have failed because the developers put their effort into designing generalizeable, extensible abstractions up front than have failed because the code had to be refactored as requirements and technology changed. > > 3. Once you have identified good interchange data you then need to > determine how to represent it. There may be various ways to represent > it. However, you should pick precisely one, unambiguous representation > for which there are algorithms to map to the other representations. This > becomes the "interchange standard". Defining an interchange > standard greatly reduces the complexity of all Seems like a good principle, but also sounds like a political rathole because everyone wants the data to be in a form that they can easily produce or consume. In a Technocracy where decisions are made on the basis of the Right Thing, this would be a very workable principle. Someone tell me when they start to sell tickets on the starship heading for that planet :-) > > ... > > Okay. That's a start. I invite you to present your ideas on what > characterizes good interchange data. I invite your input on how to > better express what I have presented above (e.g., do you agree with my > term "high value data" to describe the data that suitable for being > interchanged? Can you think of a better/more accurate term?) Sorry to be more than my usual cynical self. I think you've got some good ideas here. I'd be more interested in working backwards from success stories to see if these principles DO seem to have been exhibited than from adopting them as best practice guidelines in the absence of empirical evidence. Still, I agree with the general principle that the only standard schemas we're likely to encounter anytime soon will be EXCHANGE formats, and anything that can be done to rationalize the process of devising standardized exchange formats is a good thing.
|
