If you were to log in, you'd be able to get more information on your fellow community member.
I quote you twice to add two brief comments:
"What does that leave us with? n companies on the Web technically able to share data but having n separate data models. Each time two companies want to share data, their programmers have to cooperate on a conversion system. Before everyone can talk to anyone, we'll have to build n*(n-1) unidirectional converters (for each of n companies we need a link to n-1 other companies, thus the n*(n-1)). With just 200 companies, this turns out to be 39,800 converters."
This is the much ballyhooed EDI (Electronic Data Interchange), which, last I heard, had 42 different acceptable formats for encoding a date. What a crock.
"If we could get those 200 companies to agree on a canonical format for data exchange then we'd only need to build 400 unidirectional converters. That is a much more manageable number than 39,800 particular when it is obvious that each company should bear the burden of writing two conv...
I was going to mention XML, but the previous commentor did already. From what I have seen, people who propose using XML often get excited about creating DTDs. For general purpose use, I suppose that they are necessary, but for a particular field of endeavor, they should not be, so far as I can tell.
I believe that an XML-based data interchange can have the following properties: 1. No DTDs need to be produced or exchanged. 2. The order of the tags does not matter; data elements in a hierarchical data object are effectively "tuples". (Normalization may force a particular order though.) 3. A data consumer can accept data from a producer even when they do not both understand the exact same set of tags. If a receiver does not understand a tag, that info is simply not available. 4. If a receiver sees an unsupported tag which is above the leaf level in the hierarchy of the data object being parsed, it is still possible to read below that level for ot...