General Document Design Decisions

In Chapter 4 we discussed various issues regarding the design of XML documents that are independent of their schema representation. Here are a few of them again, from the perspective of designing your own documents.

• Naming conventions: The most pragmatic advice I can give you is to use names that will be familiar to users of your application. If a field is called Purchase Order Number on the screen or a printed report, don't give it an Element name of CustomerOrderIdentifier. Issues such as use of upper and lower case, abbreviations, and word separators are matters of style. Choose one you like, then stick to it once you've chosen.

• Elements and Attributes: This one again is kind of a religious issue. If you have defined criteria for deciding whether or not an item of data should be an Element or Attribute, and if you can apply those criteria on a consistent basis, then by all means use a mix of Elements and Attributes if you wish. If you can't be consistent, your users will thank you if you stick with Elements only.

• Structure: Should you go for a relational, nested, or some other type of structure? XML lends itself most to a nested, hierarchical structure for organizing and grouping data. Most people follow this style, but there are some exceptions. Again, your users will thank you if you make a firm design decision and apply it consistently.

• Reuse of existing logical formats: If you currently provide a facility to import a purchase order in a flat file, using an XML document of the same logical structure may allow you to use similar processing logic when importing an XML purchase order.

Again, this list is not exhaustive. These are some of the major decisions you'll have to make, but I'm sure there will be others. The next issue has more to do with the data that you include in a document than a particular set of design choices.