Abstract

While XML it rather easy to understand and use, it is also rather easy to use XML in ways which either produce ugly XML, or which may lead to problems in components further processing the XML. The topic of this lecture thus is to look at design guidelines for XML schemas, leading to good XML. Some of the simpler topics cover basic questions of how to map a data model to XML markup (e.g., when to use elements or attributes). The next question is how data should be represented in XML so that applications can process it efficiently. We also look at what part of the markup an application will actually have access to, and this is defined by the XML Information Set (Infoset), the specification underlying many XML technologies.

XML Best Practices

• Good: What you should do when using XML
• Bad: What you should not do when using XML
• Ugly¹: What you maybe have to do when using XML
• Ugly²: XML's ugly little secret …

Markup and Schemas

• XML can be encountered in different ways
  1. as somebody having to process XML documents
  2. as somebody having to understand XML documents
  3. as somebody having to generate XML documents
  4. as somebody having to design XML schemas

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

XML Views

• Other people may use different tools
  • XML is a character-based formats, 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

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
• 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

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

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

Top-Down or Bottom-Up?

• 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

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>

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; >

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!

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>

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"/>

Consistent Markup

• Decide on a strategy and stick to it
• Inconsistent markup is hard to work with
• Do not try to use markup itself for data representation
  • attribute values in single quotes should be ignored
  • empty elements using empty element tags have a special meaning

Simple Markup

• XML can be read and edited by hand
  • this depends on the application scenario and markup design
  • human-accessible XML should be a markup design goal
• Tool requirements
  • if your documents can only be used with tool xyz, something is wrong
  • XML should be used for open data formats in open environments
• Undocumented side-effects
  • data models may include more dependencies than encoded in the schema
  • clearly document these side-effects so that users are warned
  • if possible, document them in a machine readable way using a schema language

Redundant Data

• Redundant data is bad
  • database design emphasizes normalization to eliminate redundant data
  • normalization is difficult, creates complex structures, and makes data access slower
  • real-life models and databases always contain redundancies
• Redundant data is used very frequently
  • the ZIP code identifies state and city/cities
  • very few address databases normalize street names (or numbers)
• Redundancy can be used for error detection/correction

Redundancy in the Schema

• Redundant data in schemas is very bad
  • schema inspection cannot reveal the same objective behind the same markup
  • further schema development will introduce inconsistencies
• Redundant data in schemas should be avoided
  • schemas are a small and well-designed dataset
  • schema design and maintenance are important issues

Generically Generated Markup

• Some XML designers generate their schemas
  • generated schemas are more likely to be not very well-designed
  • the schema generation process may be poorly implemented
• Some schemas are based on a very generic markup
  • the structure actually is in the content, not in the markup
  • XML tools will not be very useful when working with these documents

<objects>
 <object type="person" id="o3444">
  <attribute name="name">Erik Wilde</attribute>
  <attribute name="email">dret@ischool.berkeley.edu</attribute>
  <relation type="office" object="o3445"/>
 </object>
 <object type="address" id="o3445">
  <attribute name="room">314 South Hall</attribute>
  <attribute name="phone" type="voice">+1-510-6432253</attribute>
  <attribute name="phone" type="fax">+1-510-6425814</attribute>
  <relation type="worker" object="o3444"/>
 </object>
</objects>

What is the Content of an XML Document?

• An interesting (and fruitless) discussion
  • the content is whatever you consider it to be
  • agreement between peers is necessary for data exchange
  • agreement between specification writers and toolmakers is necessary to provide tools
• DOM and XSLT were two early arrivals
  • both had an idea (and a model) of what the content of an XML document is
  • they did not have the exact same idea
• Set a normative standard for an XML document's content
  • the Infoset defines what is represented in the tree
  • people should be confident to get this information when using XML technologies

Infoset Example

What is Not in the Infoset

• Do not rely on information not available in the Infoset
  • order of attributes
  • type of quotes around attribute values
  • notation of empty elements (<elem></elem> vs. <elem/>)
  • how lines are terminated
  • entities and character references
• XML contains all this information if used as XML document
• many XML technologies are in fact Infoset technologies
  • XSDL, XSLT, XQuery, SOAP, …

XML and Modeling

• XML is about representing structured data
• XML is a format for representing trees
• Data models often are not trees
• Mapping data models to trees can be done in many ways

Assignment

• Assignment 2 is a simple Modeling task
  • we provide a sample instance and some requirements
  • create an XML version of the sample instance
  • create a DTD which is more versatile than just working for the sample instance