Copyrighted material John Tullis 10/17/2015 page 1 04/15/00 XML Part 3 John Tullis DePaul Instructor

Copyrighted material John Tullis 10/17/2015 page 2 XML Part 3 Creating a DTD One of the main tasks in creating an XML application is writing a Document Type Definition (DTD). The DTD lets us define the different pieces of data we plan to model, along with the relationships between them. The ability to include this semantic information is the source of XML's power, and its main advantage over HTML.

Copyrighted material John Tullis 10/17/2015 page 3 XML Part 3 Creating a DTD Our first step will be to create a simple DTD that mirrors the structure of the database data source that we are concerned with. Lets use the Orders table as an example. There are some ideas we can state about the database: The table we're concerned with is called Orders. Each record in the orders table represents a complete order. For each order, there are seventeen fields, of which we shall use a subset for our example. Be aware that an actual order is stored in more than one table for reasons of database normalization.

Copyrighted material John Tullis 10/17/2015 page 4 XML Part 3 Specifying useful tags Lets create a useful tag set to start:

Copyrighted material John Tullis 10/17/2015 page 5 XML Part 3 Converting tags Now lets start converting the tags into XML DTD. Start with the document element ‘order’: Note that if the closing ‘>’ appeared as ‘+>’, it would mean that document element name ‘order’ could contain one or more content model ‘order_info’ tags. That is not appropriate here….but consider its use when handling the ‘items’ within an order (hint hint). The element declaration above specifies the name of the tag as ‘order’ and the content model for the tag as containing the ‘order_info’ tag.

Copyrighted material John Tullis 10/17/2015 page 6 XML Part 3 Occurrence indicators The previous slide listed a possible ‘+>’. This is known as an “occurrence indicator”. The possible occurrence indicators are: ‘?’ - the content must appear either once or not at all. ‘*’ - the content can occur one or more times, or not. ‘+’ - the content must appear at least once, or more often. No indicator - then the content must appear exactly as described. These indicators can be combined with parentheses in any order to create complex expressions. See online documentation for details.

Copyrighted material John Tullis 10/17/2015 page 7 XML Part 3 Elements We've already decided that for our first DTD, we'll simply describe the format of a subset of the orders table. That means we'll define a tag for each field in the row. Because rows are represented by the tag, we'll include all of the field tags: Notice that the definition of the order_info element doesn't use any occurrence indicators; this means that the elements must occur in exactly this order, and will occur only once.

Copyrighted material John Tullis 10/17/2015 page 8 XML Part 3 Elements Now that we've defined the tag that contains the data for each row in the orders table, we can start defining the individual tags. Each of these tags will look like this: ………. The #PCDATA keyword above means that the tag contains parsed character data; this means that the XML parser will find only character data, no tags or entity references (more about these in a minute). There are other keywords, such as EMPTY, which means the tag can't contain anything, and ANY, which means the tag can contain text, other tags, entity references, etc.

Copyrighted material John Tullis 10/17/2015 page 9 XML Part 3 A basic orders DTD (where’s the DOCTYPE?)

Copyrighted material John Tullis 10/17/2015 page 10 XML Part 3 Attribute declarations Attribute declarations allow you to define the attributes that can appear inside a tag, as well as the kinds of data the attributes can contain. One type of attribute declaration lets you specify a set of valid values along with a default value. Here the element store_name has the attribute Company which has a list of values, along with a default value.

Copyrighted material John Tullis 10/17/2015 page 11 XML Part 3 Attributes versus tags Attributes or tags? When should something exist as a tag versus when should it exist as an attribute? In most cases, the tags versus attributes decision doesn't make any difference. However, if the data we're modelling needs to be reused, data in tags is easier to access. As an example, say the information about a store that provides a catalog on a site that is returned by a database query needs to be used as input into another query. Finding and reusing a tag is much easier than finding and reusing the Company attribute of the tag.

Copyrighted material John Tullis 10/17/2015 page 12 XML Part 3 Entity declarations The last thing we'll add to our DTD is an entity declaration. Entities allow you to define symbols that are replaced by other text before they're displayed to the user. Here's an entity that defines the symbol &t1; as equivalent to the name ”Team One.” Markup such as: Site created by &t1;! will replace the entity name with its value. If you use an entity for a common word or phrase, such as a product name, you can change all occurrences of that word or phrase simply by changing the entity declaration.

Copyrighted material John Tullis 10/17/2015 page 13 XML Part 3 More about entities An entity is the fundamental building block in XML. Each entity consists of a name and a value. Every XML document contains a root or document entity. (Remember the slide a few slides back that said - where’s the DOCTYPE?) For example: <!DOCTYPE invoice [ <!ELEMENT invoice …… ….. ]>

Copyrighted material John Tullis 10/17/2015 page 14 XML Part 3 More about entities If you declare an entity more than once, the XML parser is supposed to accept only the 1st declaration and ignore the others. It may or may not warn you! An external entity has a declaration where the replacement data is not contained within the declaration, but is instead referenced. For example: Please do not do this for the assignments!!!!! It will work but then you will be sending me 2 files for each assignment, not 1.

Copyrighted material John Tullis 10/17/2015 page 15 XML Part 3 DTD Summary This presentation has covered the basics of creating a DTD. The most important part of this task is understanding the structure of our source data and the data relationships we want our XML tags to convey. As mentioned earlier, the XML tags we've created add semantic meaning and let us process our data in much more flexible ways. These benefits will be more apparent as we continue to develop our XML application.

Copyrighted material John Tullis 10/17/2015 page 16 XML Part 3 Assignments The 1st assignment is to create a purchase order based on the “paper” copy shown in the EDI presentation. The 2nd assignment is to create an invoice based on the “paper” copy shown in the EDI presentation. Please create the files in the form of: lastname_firstname_PO.xml and lastname_firstname_Invoice.xml The format should be.txt format, and I will inport into a parser such as XMLSpy. Send both files in an as an attachment. I will check for validity, wellformedness, and content.

Copyrighted material John Tullis 10/17/2015 page 17 XML Part 3 Assignments Note that you should be able to handle multiple line items for both the purchase order and the invoice. Note that it would be nice to handle multiple shipping address for each order (thus, a single order could have items sent to different loading docks in different warehouses in a factory complex, or to different factories.