Table 3.5 Examples of More Specialized Content Models
Element Type Declaration
Meaning and Examples
- 76 -
((ice_cream|
Apple_Pie_ala_mode)
,scoops+)>
Dessert type elements are made of either one
ice_cream element
or one
Apple_Pie_ala_mode
element, followed by one or more
scoop
elements.
For example:
vanilla
chocolate
(to+,cc*,bcc*)>
An
e-mail_header
element contains at least one or
more to elements, followed by zero or more
bcc
elements, followed by zero or more bcc elements.
For example:
faraz@some_school.edu
((good*|bad*)
|(bad*|good*)*)>
Comments
can contain zero or more
good
elements
and/or zero or more
bad
elements in any order. For
example:
a funny movie
but with very cheesy special
effects.
But it has its moments
You will never guess the
ending
(junior|senior|>
(#PCDATA))
A
year
element can either have a
junior
element, a
senior
element, or contain character data. For
example:
it’s summer -- so I am not quite a
senior and no longer a junior
It can get a little confusing, but if you design your structures properly, you can represent
just about any content model using these notations.
Attribute List Declarations
Attributes, as we mentioned earlier, can be thought of as adjectives that further describe
a noun—in this case, an element. An attribute list declaration allows us to constrain the
range and types of adjectives we use to further define elements. If you’ve written a lot of
HTML documents, then you’ve been using attributes for quite some time. For example,
you know how to tweak the width of a table column or row by varying the value of the
width attribute. You also can change the alignment of text in a cell by putting a right, left,
or center value in the align attribute. But how do HTML parsers recognize these attribute
names and values? One explanation is that the HTML DTD has all those values specified
in it.
As in the previous section, we have summarized attribute list declarations in a table for a
- 77 -
quick look and have detailed this information in the paragraphs that follow.
For the parser to ensure that the attributes contained in the XML document have real
meaning (that is, are valid), the attributes need to be declared in your DTD. This is
accomplished by using
attribute list declarations
, which generally describe four key
aspects:
1.
The element to which the attribute is associated
2.
The name of the attribute
3.
The type of the attribute
4.
What the parser should do in case an attribute value is not supplied (that is, the
default value)
The general form of an attribute list looks like this (italics imply areas where specific
syntax is used):
attribute_name
attribute_type
attribute_defaults
>
The general form of an attribute list looks like this (italics imply area where specific syntax
is used):
attribute_name
attribute_type
attribute_defaults
>
The white space is tossed in to make things more legible; it has no syntactical value. The
parser doesn’t care about white space. If you have more than one attribute for a single
element, you simply repeat the last three space holders in the same order, that is, the
general form for declaring two attributes:
attribute_name
attribute_type
attribute_defaults
attribute2_name
attribute2_type
attribute2_defaults
>
and so on.
Associating the attribute with the element is pretty easy. We’ve given you the general
form; now here’s an example (we leave the type and default characteristics in the general
form for now):
- 78 -
name_type
name_default
>
If we wanted to have students be described by their name and class attributes, we’d
declare them like this:
name_type
name_default
class
class_type
class_default
>
Table 3.6 summarizes attribute type declarations.
|
