Why self describing data formats:

[James A. Donald]

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 majordomo at metzdowd.com