Michael Kay wrote:
People don't often realise that in some cases
they are choosing a name that describes how
the element relates to its parent, and in other
cases they are choosing a name that describes
what kind of thing it is (its type).
In the following XML, the element name "result" was chosen to describe how the <result> element relates to its parent (namely, test-case's expected results). Conversely, the element name "error-code" was chosen to describe a thing (namely, an error code), not a relationship.
<test-case name="B">
....
<result>
<error-code>XPTY0004</assert-eq>
</result>
</test-case>
In the following XML, the element name "altitude" was chosen to describe how the <altitude> element relates to its parent (namely, the leg's altitude constraint). Conversely, the other element named "altitude" was chosen to describe a thing (namely, an altitude), not a relationship.
<leg>
<altitude>
<at-or-above>
<altitude>29000</altitude>
</at-or-above>
</altitude>
</leg>
Do I understand correctly?
My example shows the same name (altitude) used in two different roles: (1) to describe a relationship to its parent, and (2) to describe a thing.
Is it bad data modeling to use the same name for two different roles?
/Roger
