(7) Generating XML

• Character encoding
  • use one of XML's standard encodings (UTF-8 or UTF-16)
  • if you are using mostly latin characters, UTF-8 is much more compact
  • any other character encoding may cause interoperability issues
• Pretty-printing (adding line feeds and indentation)
  • pretty-printed XML is easier to read for humans
  • pretty printed XML contains unnecessary whitespace
  • pretty-printing is good for experiments and prototypes
  • pretty printing should be switched off for production systems

(8) XML Views

• Other people may use different tools
  • XML is a character-based format, so every character counts
  • other people may choose different technologies
  • even your XML editor may choose to see things differently
• Many XML technologies use abstractions
  • useful for concentrating on the tree view
  • no full control of markup usage (automatic serialization)
  • think about working with a tree rather than working with a text file

(10) From Model to Markup

• There should be a conceptual model of the data
  • formal conceptual models for XML are an active field of research
  • informal models may use any notation (prose, graphics, combinations of these)
• Model design should omit questions of markup design
  • element/attribute decisions are not a model question
  • hierarchy/reference decisions are not a model question
  • identifying the relevant entities and their relationships is a good idea
• Document engineering never invented modeling tools
  • for document modelers, the markup is the model
  • there are no established notations for modeling documents
  • document-type parts (e.g., mixed content) are hard to include in models

(11) From Graphs to Trees

• In the model, n:m relationships may appear
  • in an address database, an address should be reusable
  • in a résumé, an organization's information should be reusable
• XML documents are trees
  • all non-tree structures must be represented by tree structures
  • in most cases, this will be done by introducing references

(12) From Markup to Model

• Start with a sample instance
  1. start with a sample instance
  2. generate a schema for the instance with some tool
  3. open up the schema where necessary
  4. try creating more example instances as different as possible/required
  5. write code for manipulating your test set of instances
• Restarting may be hard, but should be done
  • view the initial design as a test bed, not as the first version
  • after you have learned some lessons, throw everything away
  • restart by designing everything from scratch
  • content may be salvaged by writing small XSLT programs

(13) Top-Down or Bottom-Up?

• Top-Down looks at markup as a serialization of a model
• Bottom-Up builds markup incrementally from existing modules
• Both strategies have strengths and shortcomings
  • top-down tends to result in markup which looks generated
  • bottom-up tends to result in markup which is less consistent
• Consistency is an important consideration
  • if you dislike attributes, avoid them wherever possible
  • if you like attributes, use them wherever possible
  • don't mix these two styles of markup design

(14) Reuse is Good

• Elements can be reused in different contexts
  • elements then appear in the content model of more than one element
  • an address may be used for employee as well as for customer
• Content can be reused in different contexts
  • (parts of) a content model may be useful in different contexts
  • this only reuses an element's content, but not its name
• Attributes can be reused in different contexts
  • technically, attributes are element-specific and have no relations when appearing on different elements
  • when reusing attribute names, they should represent the same concept

<company>
 <people>
  <customer added="2006-08-30">
   <name>Erik Wilde</name>
   <address> ... (containing elements) ... </address>
  </customer>
  <employee id="e65783" added="2006-08-28">
   <address> ... (containing elements) ... </address>
  </employee>
  <temporary_employee id="e65784" added="2006-09-02">
   <address> ... (containing elements) ... </address>
  </temporary_employee>
 </people>
</company>

(15) Reuse is Hard (in DTDs)

• Element reuse simply lists the element in more than one content model
• Content reuse requires parameter entities
• Attribute reuse requires parameter entities
• Nested parameter entities for multi-level reuse

<!ENTITY % added "added CDATA #REQUIRED" >
<!ENTITY % employee_content "address, department?" >
<!ENTITY % employee_attributes "id CDATA #REQUIRED %added;" >
<!ELEMENT company (people) >
<!ELEMENT people (customer | employee | temporary_employee)* >
<!ELEMENT address (#PCDATA) >
<!ELEMENT customer (name, address) >
<!ATTLIST customer %added; >
<!ELEMENT name (#PCDATA)>
<!ELEMENT employee (%employee_content;) >
<!ATTLIST employee %employee_attributes; >
<!ELEMENT temporary_employee (%employee_content;) >
<!ATTLIST temporary_employee %employee_attributes; >

(17) Element vs. Attribute

• Elements and attributes are containers
  • both contain character content
• Elements may carry attributes and may contain other elements
  • for nested structures, elements must be chosen
  • if the content needs to be annotated with an attribute, an element must be chosen
  • if the item should be repeatable, an element must be chosen
• Attributes use less markup and have types
  • if the content is (unstructured) metadata, an attribute may be a good choice
  • for special types (ID/IDREF and enumerations), attributes are required
  • if simple markup is an issue, attributes may be preferable
• Be consistent in you markup design style!

(18) Hierarchy vs. Reference

• Hierarchies are only possible with 1:n relationships
  • for n:m relationships, references are the only possible representation
• Containment should be represented as hierarchy
  • containment limits the lifetime of the contained part to that of the container

<addressbook>
 <person>
  <name>Erik Wilde</name>
  <address> ... (containing elements) ... </address>
 </person>
 <person>
  <name>Katrina Lindholm</name>
  <address> ... (containing elements) ... </address>
 </person>
</addressbook>

<addressbook>
 <person address="a1">
  <name>Erik Wilde</name>
 </person>
 <person address="a2">
  <name>Katrina Lindholm</name>
 </person>
 <address id="a1"> ... (containing elements) ... </address>
 <address id="a2"> ... (containing elements) ... </address>
</addressbook>

(19) Granularity

• XML structures should identify the relevant information
  • what exactly means relevant?
  • very high granularity makes data acquisition hard
  • very high granularity makes data processing easy
• Granularity is a general problem of data modeling
  • XML is simply a syntax for representing structured data

    <phone>+1-510-6432253</phone>

    <phone cc="1" area="510" local="6432253"/>

• Overmodeling can make it hard to adapt to changes
  • treating countries as an enumeration requires a dynamic encyclopedia
  • treating a postal address as highly granular tends to break for foreign postal systems