|
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?
len
Is it possible to have the Element like
<ged.corba.Node> in
XML?. The reason is to make the definition of each Element
(structure) stricter because if you had XML that combined
different Elements from different DTD's, there would be no fear
of clashes. To be more specific, to differentiate each element in such a way
that the Element belongs to which DTD.
Any suggestions are most
welcome.
| 
Cart
