Creating DTDs

</Plan>

---

XML Namespaces

Elements are defined within a global scope.  This becomes a problem when combining elements from multiple documents.  Name collision is hard to avoid.  Namespaces were created to deal with this problem.  Without namespaces, DTD designers must prefix all element names with some sort of a prefix, obfuscating the document.

Unfortunately, namespaces don't work with DTDs.  If you want to use DTD validation, you can't use XML namespaces.

Attributes are defined within the scope of an element.  Two elements in the same document can have attributes with identical names.

---

Attributes vs. Elements

I prefer to use attributes whenever I can because I like the notion of containment.  There is no clear-cut way to decide when to use an element or an attribute.  The main decision factors are personal taste and whether your tool set provides support for attributes.  The following paragraphs discuss the pros and cons of attributes and elements.

The Argument for Elements

More people know about element content than attributes.  Attributes are more obscure.  A document with elements is generally easier to read than a document with a lot of attributes.  Elements support long text strings and linefeeds can be included in the text, unlike attributes.

The Argument for Attributes 

Attributes must be used for ID/IDREF attributes.  ID/IDREF provide useful functionality, because a DTD validator can check the validity of ID references -- this functionality is not available to elements.

Using attributes results in smaller files.  It is also easier to read attributes from the DOM.  Use attributes when you can, and use elements when you have to.

Element content can ambiguous.  For example, if you have

<Book>Mary had a little lamb</Book>

How do you know that the content is the book's title?  It's a matter of documentation.  This data is better represented inside an attribute called title, or at least inside the <Title> element.  Content makes sense for displayed documents like HTML but it doesn't necessarily make sense for data.  Attributes are more closely linked to properties in UML class diagrams; content is a document-centric concept that is not found in object-oriented modeling.

Use attributes when:

• Modeling a single-valued property on an object - a name, a date, etc.
• The property has a simple datatype and no internal structure 

Use elements when:

• Modeling arrays.  When modeling arrays, create a new element.  The element will appear multiple times.  Each data element be stored in one of the element's attributes.
• A value has structure like a C struct - create a new element that has attributes
• Order is important - create new element(s) that have the attributes that needs to be ordered
• You have a feeling that a simple string will need to be "cut up" into multiple pieces some time down the road
• You want to model your data to be reused through a document or across documents
• An address, for example, should be divided into street, city, state, zip.  There are so many additional attributes for an address that the address should be modeled as an element that has several attributes.
     <Address city="San Mateo" 
            State="CA"
            zip="94401" 
            street1="123 Ellsworth" 
            street2="Apt. 13"/>

Use element content when:

• Data can be very long; the XML document would be messy if the data appeared in an attribute
• Storing human-directed commentary such as a piece of HTML text, an error message, etc.
• You want leading and trailing whitespace to be ignored (this is not a very common situation with "data" in the UML sense)

eXcelon Persistence Considerations

Over time (time being a very compressed thing in this business :-) we will be making improvements to our internal data structures.  For excelon release 1.X and 2.0, at least, I would recommend that elements that you know to be leaves be represented as attributes in the interest of efficiency (both space and time).

- Stephanos Bacon, eXcelon Engineering Mgr.

The store must allocate space to represent a hierarchy of elements.  Since attributes only contain text, they require much less overhead.

More Information

http://www.oasis-open.org/cover/elementAttr9804.html

Shamelessly stolen from XML Authority's documentation:

Elements and attributes are both containers for information. Many times the choice between an element and an attribute seems very arbitrary, almost matter of style. While the choice may indeed be arbitrary in some cases, the 'typical' roles of elements and attributes and the different types of content models and constraints these two containers support may tip the scales in one direction or the other.

One way to look at elements and attributes suggests that elements are the 'real' containers of data, while attributes annotate elements with additional information describing the content of the element. In the case of empty elements, attributes provide additional information about why the element is present and possibly about what content it represents. This approach has been used extensively in HTML and a variety of other document-oriented schemas, and works very well with style tools like Cascading Style Sheet, which make this structural assumption a key part of its display model.

Using elements to store content and restricting attributes to annotation does have a few drawbacks, however. Element markup is much more verbose than attribute markup, with start and end tags rather than a name and some quotes. Child elements can provide more flexibility, but that flexibility isn't always necessary. In some situations, like the exchange of large quantities of small chunks of information between databases, attributes may be more efficient containers.

The 'intrinsic' differences between elements and attributes in XML 1.0 tend to define the limits of what the two containers can be used for. The most fundamental difference, which will likely continue to hold through future iterations of XML development, is that elements can contain child elements as well as content, while attributes can only hold content. If it seems at all likely that you'll need to break down the information stored in a container, make that container an element.

Attributes do have some advantages over elements, however. In XML 1.0, and in the XML Schema working draft, only attributes may have default values assigned to them by the schema. In XML 1.0, attributes also have much stronger constraints - you can limit the acceptable values of an attribute to a class of values (notation or entity names) or provide an enumerated list of acceptable values. XML Schemas may change this, and XML Authority provides a larger list of possible constraints (data types) for elements than is available in XML 1.0.

Another field to explore before settling on whether to use elements or attributes is your processing software and parser. While element and attribute information is equally accessible in a tree-based interface (like those using the W3C's Document Object Model - DOM), developers working with stream-based interfaces (like the Simple API for XML - SAX) may have their own set of preferences for document structures.

For more resources describing the issues involved in element and attribute usage, see Robin Cover's SGML/XML Elements versus Attributes article.

---