Databases Reference
In-Depth Information
Schema guidelines
It's important to have a clear set of guidelines for schema design. This not only
warrants that the best practice is followed, it also ensures that schemas are created
consistently, making them more reusable, easier to combine, simpler to understand,
and easier to maintain.
Element naming
Consistent naming of elements within an XML Schema will ensure that schemas are
easier to understand, and reduce the likelihood of error due to names being spelt
differently within a different context.
Name length
While there is no theoretical limit on the length of an element or attribute name, you
should try and limit them to a manageable length. Overly long names can reduce the
readability of a document as well as make them overly bloated, which, in extreme
cases, could have performance implications.
We tend to try and limit names to a maximum of 15 characters; now this may not
always be possible, but there are a number of simple strategies.
Compound names
For element and attribute names that are made up of multiple words, we follow
the practice of capitalizing the first letter of each word (often called camel case).
For example, we would write the name 'shipping address'
as
shippingAddress
.
Another approach is to use a separator, that is, a hyphen or an underscore
between words. Personally, we don't find this as readable as well as resulting in
marginally longer names. Whichever approach you use, you should ensure that
you do so consistently.
For types (for example,
complexType
and
simpleType
), we follow the same
convention but prefix the name with a '
t
' in order to easily distinguish it from
elements and attributes.
An alternative convention is for type names to have the word
Type
'
at the end. However, we are not as keen on this convention as it can
lead to type names finishing in
TypeType
. For example we have the
element
auctionType
; using this convention; its type name would be
auctionTypeType
.
