James A. Donald: > > In the case of XML, yes there is a parsing engine, > > and if the structure of the DTD reflects the > > structure of the algorithm, then indeed it makes > > things much easier. But usually the committee have > > not thought about the algorithm, or have unresolved > > disagreements about what the algorithm should be, > > leaving the engineer with problems that are at best > > extremely difficult to solve, and are at worst > > impossible to solve. Ideally the DTD should be > > developed in parallel with the program that > > processes the XML. In that case, you get the > > parsing engine doing a lot of work for free, so the > > engineers do not have to reinvent the wheel. But if > > the DTD is written first by one group, and the > > program second, by another group, the second group > > is usually hosed good.
Will Morton: > The situation is improved slightly with XML schemas, > as one can use frameworks like XMLBeans > (http://xmlbeans.apache.org/) to get the protocol much > closer to the code. This can help a bit, but doesn't > change the fundamentals. > > You're still right in that if you have one group > developing the code and another the protocol, you're > probably screwed, but isn't this just as true (perhaps > moreso) if you're rolling your own protocol structure > instead of using XML? With XML, alarmingly great flexibility in the protocol is easy and less work for the people designing the protocol - the protocol may be inordinately flexible because of laziness, carelessness, unresolved disagreement, or papered over disagreement, resulting in tag soup. With a protocol that is not self describing, the committee devising the protocol have to actually agree on what the protocol actually is. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
