DTD Elements vs Attr

DTD Considerations: Elements vs. Attributes

When designing the structure of your XML document (which might be formalized in a DTD or schema), you need to decide whether to represent pieces of information using child elements or attributes.

As discussed previously, there are no strict XML syntax rules dictating this choice, but DTD/schema design principles and best practices offer guidance.

Reviewing the Options

Let’s revisit the person example:

Attribute for gender:

<person gender="female">
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

Element for gender:

<person>
  <gender>female</gender>
  <firstname>Anna</firstname>
  <lastname>Smith</lastname>
</person>

Both are valid XML and convey the same information. The choice impacts structure, validation capabilities (especially with XSD), and ease of processing.

Guidelines for Choosing (Reiteration)

These guidelines help in making a consistent and logical choice:

• Use Elements for:
• • Core data content.
• • Information that might contain structure (e.g., address, date components).
• • Information that can occur multiple times (e.g., phone numbers, email addresses).
• • Data that might need future expansion with more details.
• • Improving readability when many pieces of information are associated with an element.
• Use Attributes for:
• • Metadata (information about the data, e.g., xml:id, unit, language, status).
• • Simple, atomic values that don’t need structure.
• • Controlling processing or presentation (e.g., type, role).

Consider the date example again:

Attribute (ISO 8601 format recommended):

<note date="2024-07-01">
  ...
</note>

Structured Element (Often preferred for flexibility):

<note>
  <date>
    <year>2024</year>
    <month>07</month>
    <day>01</day>
  </date>
  ...
</note>

The structured element approach makes it easier to query or process just the year, month, or day individually.

DTD/Schema Implications

Your choice affects how you define the structure in a DTD or schema:

• Attributes in DTDs: Defined using <!ATTLIST ...> declarations, specifying the attribute name, type (e.g., CDATA, ID, IDREF, enumerated), and default value/requirement (#REQUIRED, #IMPLIED).
• Elements in DTDs: Defined using <!ELEMENT ...> declarations, specifying the element name and its allowed content model (e.g., other elements, #PCDATA, EMPTY).
• XML Schema (XSD): Offers much richer capabilities for both elements and attributes, including precise data types (integer, date, boolean, patterns), occurrence constraints (min/max occurs), and more complex structures. The choice between element/attribute can have more significant validation implications with XSD.

While DTDs have limitations (e.g., basic type checking for attributes, no namespace support), the fundamental decision impacts how you declare your intended structure.

Avoid overloading elements with too many attributes, as it can harm readability and maintainability:

Less readable example:

<note to="Tove" from="Jani" date="2024-07-01" priority="high" status="unread" ... />

Metadata like priority or status might be suitable as attributes, but core content like to, from, date are often better as elements.

Metadata Exception: Identifiers

As highlighted before, using attributes for unique identifiers is a standard and recommended practice. Use the xml:id attribute for this purpose.

<messages xmlns:xml="http://www.w3.org/XML/1998/namespace">
  <note xml:id="p501">
    <to>Tove</to>
    ...
  </note>
  <note xml:id="p502">
    <to>Jani</to>
    ...
  </note>
</messages>

The xml:id attribute clearly designates a unique identifier for referencing the element, fitting the definition of metadata.

In conclusion, prioritize elements for content and structure, and use attributes for metadata, identifiers, and simple configuration flags.