[Home] [By Thread] [By Date] [Recent Entries]
One place you see this is in automatic translations from code or IDL. I had to work with some xml that was automatically created from the java objects created for CORBA messages, and they were pretty awful, about what you show. The IDL developers rightly create readable element names according to notions of naming conventions, but those names aren't intended to be instantiated in the message instance. It's not so easy to get good element names from such IDL by machine. Cheers, Tom P [Bullard, Claude L (Len] > It's legal. That is how the Oster DTD element type names were designed (early 90s). > One can do fancy tricks with microparsing that way. On the other hand, a nested > structure can achieve this as well. As to naming collisions, is the system so open that > you can't control that without resorting to element dot naming? > > While we're here and in the best practices category, > I've seen some pretty awful type trees lately > designed by object programmers determined beyond all good sense to carry > naming conventions all the way from root to leaf without stopping to consider > the structure provides implicit nested naming. > > <paramTables> > <paramTable> > <paramTableName></paramTableName> > <paramTableDescription></paramTableDescription> > <paramColumns> > <paramColumn> > <paramColumnName></paramColumnName> > <paramColumnPosition></paramColumnPosition> > <paramColumnType></paramColumnType> > <paramColumnDescription><paramColumnDescription> > <paramColumnUnits></paramColumnUnits> > <paramColumnMin></paramColumnMin> > <paramColumnMax></paramColumnMax> > <paramColumnIndex></paramColumnIndex> > <paramColumnUnique></paramColumnUnique> > <paramColumnWidth></paramColumnWidth> > <paramColumnPrecision></paramColumnPrecision> > </paramColumn> > > The ratio of data to markup in this design is probably less than > 5% data. Anyone care to comment on why one would choose > to work up this kind of scheme or what it is like to use in > practice? >
|

Cart



