Databases Reference
In-Depth Information
A common mistake is to use a flat structure, and then name the elements to
compensate for this, for example, changing the name to
<order_shipTo_address_
city>
. While this provides more context than just
<city>
, it introduces a whole set
of other problems, including:
It makes your XML far harder to read, as well as more bloated.
The relationships are no longer visible to your XML parser. This makes XPath
manipulation, XSLT mappings, and so on a lot more complex and onerous.
It reduces the opportunity for reuse; for example, each address element will
have to be redefined for every single context in which it is used. This is likely
to lead to inconsistent definitions as well as make changes harder to manage.
If you see elements named in this fashion, for example,
<a_b_c>
,
<a_b_d>
, it's a
pretty good clue that the schema has been poorly designed.
•
•
•
Data semantics
Another key to our data model is the semantics of our data. Looking at the preceding
example, it is obvious what the
<state>
element contains, but the exact format of
that data is not as obvious; that is, it could be Victoria, VIC, Vic, 0, and so on.
While different target systems will have different requirements, it is important that
a set of semantics are agreed upon for the canonical model, so that these differences
can be isolated in the Virtual Services layer.
While semantics can be enforced within our XML Schema through the use of facets
such as
enumeration
,
length
,
pattern
, and so on, this is not always the best
approach. This is an area we examine in more detail in
Chapter 13
,
Building
Validation into Services.
Using attributes for metadata
A common debate is when to model XML data using elements and when to use
attributes, or whether attributes should be used at all.
Elements are more flexible than attributes, particularly when it comes to writing
extensible schemas, as you can always add additional elements (or attributes) to
an element. However, once an attribute has been defined, it can't be extended
any further.
One approach is to use attributes for metadata and elements for data. For
example, on some of our query-based operations (for example.
getSellerItems
,
getBuyerItems
) we have defined two attributes,
startRow
and
endRow
, which are
used to control which portion of the result set is returned by the query.
