DTD和XML Schema
Download
Report
Transcript DTD和XML Schema
DTD和XML Schema
第3章
DTD 和XML Schema
3.1 DTD
3.2 XML Schema
3.3 XML Schema 和DTD的区别
3.1 DTD
3.1.1 DTD简介
3.1.2 DTD的存在方式
3.1.3 XML元素的声明
3.1.4 DTD的属性声明
3.1.5 DTD的实体声明与引用
3.1.1 DTD简介
Document Type Definition 文档类型定义
DTD是一套关于关于标记的语法规则，详细地描述一
组XML文档的结构。
DTD文件严格地规定了将以它为标准的所有实例XML
文档的树状层次结构的全部细节。
对XML文档的有效性验证是可选的
–
–
对文档有效性验证会降低系统的性能
使用DTD对XML文档进行有效性验证将限制其扩展性
3.1.2 DTD的存在方式
DTD语句也称DTD声明，它使用一套与XML完全不同的语法规
则进行编写。
内部DTD：存在于XML文档本体中元素、属性或实体的DTD声
明
–
–
外部DTD：对XML元素和属性等的声明包含在一个单独的DTD
文件中。
–
–
–
以”<! DOCTYPE”开始，以”]>”结束
DOCTYPE是DTD的关键字，必须大写
方便共享
SYSTEM引用：主要用于一个作者或组织所编写的众多XML文档中
通用的DTD
PUBLIC引用：引用公开给公众使用的DTD
内部DTD和外部DTD结合使用
3.1.3 XML元素的声明
示例 内部DTD
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE REGARD [
<!ELEMENT REGARD (#PCDATA)>
]>
<REGARD>
HelloXML!
</REGARD>
3.1.3 XML元素的声明
列出元素
–
–
–
–
要为一个文档创建适当的DTD，第一步是了解用
DTD中定义的元素编码的信息结构。
所编写的DTD要为每个元素作元素声明。每一元素
声明列出元素名和它的子元素。
清单：需要编写DTD结构完整的XML文档 31.doc
表：学生成绩统计中的元素 表3-1.doc
3.1.3 XML元素的声明
在合法的XML文档中使用的每项标记都要在DTD
中的元素声明中加以声明。一项元素声明指明
了元素名称和元素可能的内容。
元素声明的基本语法：
<!ELEMENT 元素名称 元素内容描述>
– ELEMENT是DTD的关键字，必须大写
– 元素名：命名规则与标记的命名规则同
– 元素内容描述：规定该元素将包含哪些子元素及子
元素之间的顺序，或者对于不包含子元素的元素定
义其数据类型。
3.1.3 XML元素的声明
1.
2.
3.
4.
空元素类型
ANY元素类型
父元素类型
只包含文本的元素类型
1、 空元素的声明
即没有内容的元素
<!ELEMENT 元素名 EMPTY>
例如：<!ELEMENT HR EMPTY>
这样，在XML文件中，就可以使用一个空元素
<HR/>。
2、ANY元素类型
是XML为某些结构性比较差的元素提供的说明方法，它
对该元素不作限制。
–
–
–
–
可以包含任何在该DTD中声明过的子元素
这些子元素的出现次数与次序不作限制
可以包含文本数据，即（#PCDATA）型数据
数据内容与子元素可以交错出现
语法： <!ELEMENT 元素名 ANY>
例如：<!ELEMENT SEASON ANY>
关键词ANY（也要区分大小写）表明所有可能的元素以
及可解析的字符数据都可以是SEASON元素的子元素。
对于根元素特别是未结构化的文档，使用ANY常见，但
在其他大多数情况下，尽量避免使用。
4.只包含文本的元素类型
元素的内容完全是文本形式的元素类型
例如：<!ELEMENT YEAR (#PCDATA)>
该声明说明YEAR只能包含可析的字符数据，即非标记
文本，但它不能包含自己的子元素。所以，下面这个
YEAR元素是合法的：
<YEAR>1998</YEAR>；
不合法：
<YEAR>
<MONTH>January</MONTH>
<MONTH>February</MONTH>
</YEAR>
3.父元素类型
XML文档本身通过元素之间的嵌套关系描述
了数据（元素）之间的树状结构关系。
子元素声明中包括：
–
–
–
子元素名称
子元素出现的次数及次序
见下图：结构符合的具体描述
一个元素的各个子元素之间可以以任意顺序出
现，也可以强制遵循一定的顺序。
–
不要求顺序的子元素
结构
符号
使用方法
应用实例 实例说明
( )
将括号内的元素或数据类 (A,B,C)
型合并为一个单元
A,B,C可能是元素或#PCDATA数
据，将A,B,C合成一个单位
,
元素或数据以出现的顺序 (A,B,C)
排列
元素A,B,C以出现的顺序排列
*
该元素或是由括号形成的 A*
单位出现任意次数，包括 (A,B)*
0次
前一例说明元素A可能出现任意
次；后一例表明元素A和B以一前
一后的次序出现任意次
+
该元素或由括号形成的单 A+
位出现任意次数，不包括 (A,B)+
0次
前一例说明元素A可能至少出现
一次；后一例表明元素A和B以一
前一后的次序至少出现一次
?
该元素或由括号形成的单 A?
位出现至多出现一次，即
0次或1次
元素A出现0次或1次
|
在该元素范围内的元素只 (A|B|C)
能并必须出现一个
元素A出现或B出现或C出现
3.父元素类型
考虑下面的DTD定义：
同样，下面这个XML文件也是有效的：
<!ELEMENT 联系人(姓名 EMAIL)> <联系人>
<!ELEMENT 姓名(#PCDATA)>
<EMAIL>[email protected]</EMAIL>
<姓名>张三</姓名>
<!ELEMENT EMAIL(#PCDATA)>
遵从这个DTD的XML文件可以为： </联系人>
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
在DTD定义中仅仅用空白符分隔
了元素“联系人”的两个子元素，
这说明并没有严格要求两个元素
出现的顺序，因此上面两种写法
都是允许的。
3.父元素类型
要求顺序的子元素
– 在上面例子中，如果我们使用逗号“，”来分隔两
个子元素，那么XML文件中，元素“姓名”就必须
出现在元素“EMAIL”前面。也就是说，如果我们把
DTD定义为下面的形式：
–
<!ELEMENT 联系人(姓名, EMAIL)>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
3.父元素类型
那么下面的文件是有效的：
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
而下面这个文件不是有效的，因为它把元素“EMAIL”放在了元素
“姓名”之前，这是不合规定的：
<联系人>
<EMAIL>[email protected]</EMAIL>
<姓名>张三</姓名>
</联系人>
3.父元素类型
重复元素
<!ELEMENT 联系人(姓名，EMAIL+)>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
它说明一个“联系人”元素中必须含有一个
“姓
名”元素，后面接一个或多个“EMAIL”元素。
这样，下面的这段XML文件是“有效的”。
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
<EMAIL>[email protected]</EMAIL>
<EMAIL>[email protected]</EMAIL>
</联系人>
<联系人>
<姓名>张三</姓名>
</联系人>
这个片段不是有效的，因为
它没有“EMAIL”元素，而
“+”代表了“一个或多个”。
如果你需要表示“零个或多
个”，那么应该使用字符
“*”。
3.父元素类型
成组元素:子元素可以使用括号并为一组。
– 下面的DTD片段说明，一个“联系人”元素中可以
有一个或多个“姓名/EMAIL”子元素对，并且在每
个子元素对中，“姓名”都放在“EMAIL”之前。
<!ELEMENT 联系人(姓名，EMAIL)+>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
3.父元素类型
符合这个DTD的XML文件可以是：
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
<姓名>李四</姓名>
<EMAIL>[email protected]</EMAIL>
<姓名>王五</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
注意，仅仅是因为“+”由括号里面移到括号外面，元
素“联系人”的内容就大大不同了。
OR或
符号“|”描述了一个OR操作。
因此，下面的DTD片段所规定的XML元素是：所
有的“联系人”元素应该有一个“姓名”子元
素，同时，在此之后还应该有一个“电话”或
一个“EMAIL”元素，但不能同时有“电话”和
“EMAIL”两个元素。
<!ELEMENT 联系人(姓名，(电话|EMAIL))>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT 电话(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
OR或
<联系人>
<姓名>张三</姓名>
</联系人>
这个例子是一个“无效的”XML片段，因为DTD中规定或者有一个
“电
话”元素，或者有一个“EMAIL”元素，但上面这个例子中两种元素
都
没有。
<联系人>
<姓名>张三</姓名>
<电话>12345678</EMAIL>
<EMAIL>[email protected]</EMAIL>
</联系人>
同样，这个例子仍是一个“无效的”XML片段，因为它既有“电话”元素，
又有“EMAIL”元素。
OR或
一个符合上述DTD定义的“有效的”XML文件的定义应该是：
<联系人>
<姓名>张三</姓名>
<电话>12345678</EMAIL>
</联系人>
或者是：
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
注意：在一个组中，只允许使用一种连接符（例如“，”或“|”）。
因
此，象下面这样定义的DTD是不合法的：
<!ELEMENT 联系人(姓名，电话|EMAIL)>
要想使用多种连接符，只有通过创建子组的方式，使用
<!ELEMENT 联系人(姓名，(电话|EMAIL))>
可选子元素
字符“?”说明一个子元素是可选的，它可以出现，也可以不出现。
因此，在下面的DTD中，我们规定，每一个“联系人”都必须有一个
“姓名”子元素，同时或者有一个“电话”子元素，或者有一个
“EMAIL”
子元素，此外，它还可以包含一个“地址”子元素，也可以不包含
这
种元素。
<!ELEMENT 联系人(姓名，(电话|EMAIL)，地址?)>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT 电话(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
<!ELEMENT 地址(街道，城市，省份)>
<!ELEMENT 街道 (#PCDATA)>
<!ELEMENT 城市 (#PCDATA)>
<!ELEMENT 省份 (#PCDATA)>
可选子元素
下面的XML片段是“有效
的”：
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</E
MAIL>
<地址>
<街道>五街1234号</街
道>
<城市>北京市</城市>
<省份>北京</省份>
</地址>
</联系人>
同样，下面这段不包含“地址”
元素的XML片段也是“有效的”：
<联系人>
<姓名>张三</姓名>
<EMAIL>[email protected]</E
MAIL>
</联系人>
混合内容
一个元素中既希望包含子元素，也希
望包含纯文本。XML中允许这种使用方
法，并把这种元素称为混合内容的元
素。
在下面的例子中，“联系人”就是一
个混合元素。
混合内容
<?xml version = “1.0” encoding=“GB2312” standalone = “yes”?>
<!DOCTYPE 联系人列表 [
<!ELEMENT 联系人列表 (联系人)*>
<!ELEMENT 联系人(姓名|电话|EMAIL|#PCDATA)*>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT 电话(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
]>
<联系人列表>
<联系人>
<姓名>张三</姓名>
<电话>(010)62345678</电话>
<EMAIL>[email protected]</EMAIL>
这是关于张三的信息
</联系人>
</联系人列表>
注意，由于在“(姓名|电话|EMAIL|#PCDATA)”之外有“*”，所以在元
素
“联系人”中可以包含零个或多个“姓名”、电话、EMAIL和纯文本字
小结
除了根元素外，在定义其它元素时使用关键字ANY都
是不好的习惯。一般来说，在写一个XML文件时需要
严格遵循DTD的规则，这时，一个定义明确的DTD，
虽然表面上似乎充满了条条框框，但实际上会使你
在书写XML文件时有规可循，反而方便了你的工作和
语法分析器的工作。相反，一个在元素定义中充满
了ANY的DTD，反而可能会搞得你不知所措，一头雾
水。
不能对不同的元素使用相同的元素名，即便这些元
素的内容、包含的子元素不同也不行，因为它只会
引起文件各个元素的混淆，使文件的可读性大打折
扣。
小结
定义元素时，顺序是无关紧要的。因此
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT 联系人列表 ANY>
<!ELEMENT 联系人(姓名)>
和
<!ELEMENT 联系人列表 ANY>
<!ELEMENT 联系人(姓名)>
<!ELEMENT 姓名(#PCDATA)>
所定义的文件结构是完全相同的。
小结
元素名的第一个字母必须是字母、或下划线（_）、
或冒号（：），后跟字母、数字、句号（.）、冒号、
下划线、连结号（-）的组合，并且不能包含空白符，
不能以“xml”开头。
另外，尽管元素的第一个字母使用冒号是合法的，
但最好避免这样做，因为它会引起混淆。
需要注意的是，尽管XML1.0标准允许使用任何长度
的文件名，但是实际的XML处理器常常会限制标记名
的长度。
习
题
1．何谓DTD？在XML文件中使用DTD有何好处？
2．在合法的XML文档中使用的每项标记都要在
DTD中的元素声明中加以声明，请简述以下几
种声明方式：
序列；零或多个子元素零；选择。
习
题（续）
3．请撰写一个实际XML文件来说明引用底下的
DTD？
<?xml version=”1.0”?>
<!ELEMENT book (title,author,breakline,publish,price,language)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>
<!ELEMENT publish (#PCDATA)>
<!ELEMENT price (#PCDATA)>
<!ELEMENT language (#PCDATA)>
<!ELEMENT breakline EMPTY>
习
题（续）
4．请撰写一个实际XML文件来说明下
面的DTD?
<? Xml version = “1.0” encording = “GB2312”?>
<!DOCTYPE 汽车[
<!ELEMENT 汽车（品牌，车主，保险公司*，银行贷款？，维修地点）〉
<!ELEMENT 品牌(#PCDATA)〉
<!ELEMENT 车主(#PCDATA)〉
<!ELEMENT 保险公司(#PCDATA)〉
<!ELEMENT 银行贷款(#PCDATA)〉
<!ELEMENT 维修地点(#PCDATA)〉
]>
3.1.4 DTD的属性声明
开始标记和空标记可包含由等号“=”分割开
的成对的属性名和属性值
属性包含有关元素内容信息，而不是元素内容
本身。
元素可具有多个属性
结束标记不能带属性
3.1.4 DTD的属性声明
属性是XML提供的描述元素某些性质的
信息。
在一个有效的XML文档中，属性要经过
DTD的属性说明。
在DTD声明中，属性的声明语法为：
<!ATTLIST 元素名 属性名 属性类型 属性默认值类型>
– 元素名为属性所属的元素的名称
– 属性类型是对属性值的约束
3.1.4 DTD的属性声明
例如：
<商品 类型 =“服装” 颜色 = "黄色">
元素名是“商品”；属性名是属性的命名， “类型”
和“颜色”是属性名；默认值说明在XML文件中，如果
没有特别说明属性的取值，语法分析器默认它具有的
取值；属性类型则用来指定该属性是属于有效属性类
型中的哪种类型。
注意：由于ATTLIST是一个属性的列表，它可以包含很
多属性，在实际应用中，一个元素也经常有多个属性。
属性默认值类型
1) #IMPLIED：属性值可有可无的属性，而且也无须在DTD
中为该属性提供缺省值。
语法：<!ATTLIST 元素名称 属性名称 #IMPLIED>
有时用户在不强制指定特定默认值的情况下省略特定属
性值。
例如，可以拥有一个SHIRT（衬衣）元素，其具有一个
声明为NMTOKEN的SIZE属性。但有些衬衫属于均码，没
有尺寸。可以省去SIZE这个值，并且处理器隐含这个衬
衫属于均码，
<!ATTLIST SHIRT SIZE NOTOKEN #IMPLIED >
<SHIRT>---符合上述定义
<SHIRT SIZE=“”>---不符合上述定义
属性默认值类型
2) #REQUIRED：必须赋值的属性
关键字REQUIRED说明XML文件中必须为这个属性给出
一个属性值。
与提供默认值相反的情况，文档类型设计者需要强制
作者选择一个值。如果属性值既重要又无法可靠地默
认确定，那么设计者可以要求作者用该属性默认值来
指定。
例如：<!ATTLIST IMAG URL CDATA #REQUIRED>
这种情况下，DTD设计者使URL属性在所用IMAG元素上
都成为必需。之所以这样做是因为如果没有一个URL
定位图像文件，则此IMAGE元素没有任何意义。
属性默认值类型
3) #FIXED：表明该属性一定要出现，且固定为特定值，不许用其
他值。
当需要为一个特定的属性提供一个缺省值，并且不希望XML文
件的编写者把你的缺省值替代掉。这时候，就可使用FIXED关
键字，同时为该属性提供一个缺省值。
4) 特定属性值表明该属性的默认值，当XML文档中没有显式给出
该属性的取值时，取此值。当该属性的取值已经显式地给出，
则为给出值。
如果不使用上面任何一种关键字的话，该种属性就是属于这种
类型。对于这种属性，你需要在DTD中为它提供一个缺省值。
而在XML文件中可以为该属性给出新的属性值来覆盖事先定义
的缺省值，也可以不另外给出属性值，后一种情况下它就默认
为采用DTD中给出的缺省值。
属性类型
类 型
含 义
CDATA
字符数据不是标记的文本
枚举型
可能取值的列表，可从中选出正确的值
ID
不能被文档中其他任何ID类型属性共享的数字，具有惟一性
IDREF
文档中元素的ID类型属性的值
IDREFS
由空格分开的若干个ID
ENTITY
在DTD中声明的实体名
ENTITIES
在DTD中声明的若干个实体的名字，彼此间由空格分开
NMTOKEN
XML名称
NOTATION
在DTD中声明的注释名
NMTOKENS
由空格分开的多个XML名称
属性类型
（1）CDATA类型：是最简单的属性类型，也是约束最少的属性类型。即
Character Data 缩写，代表该属性值为一般的文字，除此没有其它限
制．
语法：
<!ATTLIST 元素名称
例如：
属性名称
CDATA
属性默认值类型>
<?xml version = "1.0“ encoding="GB2312" standalone = "yes"?>
<!DOCTYPE 剧本 [
<!ELEMENT 剧本 ANY>
<!ELEMENT 对话 (#PCDATA)>
<!ATTLIST 对话 演员 CDATA>
]>
<剧本>
<对话 演员=“某甲”>我可不这么认为！</对话>
<对话 演员=“某乙”>为什么呢？</对话>
</剧本>
属性类型
（2）枚举型：列举了该属性所能取得的全部值．
语法：
<!ATTLIST 元素名称 属性名称 (可选属性值1|可选属性值2|……|可选属性值N) 属性
默认值类型>
例如：
<?xml version = “1.0”
encoding=“GB2312” standalone = “yes”?>
<!DOCTYPE 购物篮 [
<!ELEMENT 购物篮 ANY>
<!ELEMENT 肉 EMPTY>
<!ATTLIST 肉 类型( 鸡肉 | 牛肉 | 猪肉 | 鱼肉 ) “鸡肉”>
]>
<购物篮>
<肉 类型 = “鱼肉”/>
<肉 类型 = “牛肉”/>
<肉/>
</购物篮>
注意，在上面这个例子中，给属性“类型”定义的缺省值是“鸡肉”，所以“购
物篮”中的第三个元素的“类型”属性取值为“鸡肉”。
属性类型
（3）NMTOKEN和NMTOKENS类型：一个有效的XML
名称，必须以字母或者下划线开始，之后是字母、数
字下划线、短横线或圆点，而且不能包含空格。
后者表明属性值可能由若干个满足NMTOKEN属性要
求结合在一起形成的，即多个NMTOKEN之间可能存
在空格。
语法：
<!ATTLIST 元素名称
性默认值类型>
属性名称 NMTOKEN|NMTOKENS 属
属性类型
例如1：
<!ATTLIST Employee security_level NMTOKEN
#REQUIRED>
<Employee security_level=“trusted”>
上述代码表示元素E m p l o y e e有一个名为s e c u r i t y
_ l e v e l的属性，其值符合X M L名称记号的规则。我们
可以用它来控制对机密文档的访问。由于定义属性列表时
使用了N M TO K E N，而不是枚举类型，文档创作者只
需创建新的值，就能够适应新的安全级别要求，而不必每
次都编辑D T D。只要符合我们前面介绍的有效的N M TO
K E N值应该遵守的规则任何值都可以作为这种属性的值。
属性类型
例如2：
<!ATTLIST Employee security_compartments NMTOKENS
#IMPLIED>
<Employee security_compartments=“red green mega ultra ”>
这个职员能够访问名为r e d、g r e e n、m e g a和u l t r a的安
全区域。就类型而言，这些都是有效的N M TO K E N值。与枚举类型
不同，解析器不检查这些值的有效性。文档的作者必须确保自己使
用了适当的名称。
属性类型
例如3：
<!ELEMENT 数据(#PCDATA)>
<!ATTLIST 数据 安全性( ON | OFF ) "OFF“
授权用户 NMTOKENS #IMPLIED >
Xml文件：
<数据 安全性="ON" 授权用户 = "IggieeB
SelenaS GuntherB">
blah blah blah
</数据>
属性类型
NMTOKEN属性类型
–
–
NMTOKEN属性类型限定属性值为有效的XML名
称。
当需要从大量名字中选取不是XML的规定部分但
与XML命名要求相符的名字时，就能体现
NMTOKEN的用途。
属性类型
NMTOKENS属性类型
–
NMTOKENS属性类型几乎就是NMTOKEN的复数
形式。这种类型的属性可以使如下情况合法——属
性由若干XML名称字组成，彼此间由空格分隔。
通常可为使用NMTOKEN属性相同的理由而使用
NMTOKENS属性，但仅仅在需要多个名字的时候。
属性类型
（4）ENTITY和ENTITIES类型：当属性值是一个外部实体的引用时，
用ENTITY来说明属性类型。
一般来说，当属性值是一个内部实体引用时，将属性类型声明为
CDATA即可。
实体属性类型
实体类型的属性值属于一般实体，如前所述，它的定义方式是：
<!ENTITY 实体名 “实体内容”>
或利用SYSTEM定义外部实体，方式为：
<!ENTITY 实体名 SYSTEM “外部文件名”>
– 引用方式为：
&实体名；
使用关键字ENTITY，则声明一个属性是实体类型，它的取值为已定
义的实体。请看下面例子：
–
属性类型
<?xml version = "1.0" encoding="GB2312“
standalone = "yes"?>
<!DOCTYPE 文件[
<!ELEMENT 文件 ANY>
<!ELEMENT 电影 EMPTY>
<!ATTLIST 电影 来源 ENTITY #REQUIRED>
<!ENTITY pic SYSTEM “1-5.jpg">
]>
<文件>
<电影 来源 = "pic">
</文件>
属性类型
ENTITY属性类型
–
–
ENTITY类型的属性提供把外部二进制数据和外部
不可析实体链接到文档中的能力。ENTITY属性值
为DTD中声明的不可析通用实体名，该实体名链接
到外部实际数据。
经典的ENTITY属性的例子就是图像。图像由另一
URL处可用的二进制数据组成。
属性类型
ENTITIES属性类型
–
ENTITIES属性类型几乎就是ENTITY的复数形式。
若干由空格分隔的不可析实体名组成ENTITIES类
型属性的值。每一实体名指向一个外部非XML数
据资源。
属性类型
（5）NOTATION类型：
现实世界中存在着很多无法或不易用XML格式组织的数据，例如图象、声音、
影象等等。对于这些数据，XML应用程序常常并不提供直接的应用支持。通
过为它们设定NOTATION类型的属性，可以向应用程序指定一个外部的处理
程序。例如，当你想要为一个给定的文件类型指定一个演示设备时，可以
用NOTATION类型的属性作为触发。
要使用NOTATION类型作为属性的类型，首先要在DTD中为可选用的记号作出
定义。
<!NOTATION 格式 SYSTEM|PUBLIC 处理程序的URI>
<!ATTLIST 元素名称 属性名称 NOTATION 属性默认值类型>
例如：
属性类型
在下面这个例子中，为“电影”元素指定了两种可选设备：
一种是movPlayer.exe，用来播映.mov文件，另一种则用来绘制GIF
图象。
<?xml version = "1.0” encoding="GB2312“ tandalone = "yes"?>
<!DOCTYPE 文件[
<!ELEMENT 文件 ANY>
<!ELEMENT 电影 EMPTY>
<!ATTLIST 电影 演示设备 NOTATION (mp|gif) #REQUIRED>
<!NOTATION mp SYSTEM "movPlayer.exe">
<!NOTATION gif SYSTEM "Image/gif">
]>
<文件>
<电影 演示设备 = "mp"/>
</文件>
属性类型
NOTATION属性类型
–
NOTATION属性类型指定属性值为DTD中声明的
记号名。这一属性的默认值也必须为DTD中声明的
记号名。
属性类型
（6）ID类型：
ID是用属性值的方式为文件中的某个元素定义唯一标识
的方法
ID的值必须是一个有效的XML名称，它由字母、数字或下
划线开始，名字中不能出现空白符。
不要给ID类型的属性事先指定缺省值，这很容易引起不
同的元素具有相同的标识的情况，更不能使用FIXED型的
缺省值。此类属性经常使用REQUIRED缺省类型，当然，
这也不是必须的。有的应用并不要求每个元素都有自己的
标识，所以，也可以使用IMPLIED缺省类型。
属性类型
<?xml version = "1.0" encoding="GB2312“ standalone = "yes"?>
<!DOCTYPE 联系人列表[
<!ELEMENT 联系人列表 ANY>
<!ELEMENT 联系人(姓名,EMAIL)>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
<!ATTLIST 联系人 编号 ID #REQUIRED>
]>
<联系人列表>
<联系人 编号="1">
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
<联系人 编号="2">
<姓名>李四</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
</联系人列表>
属性类型
ID属性类型
–
–
–
一个ID类型的属性标识文档中惟一的元素，编辑工具和其余
应用程序通常使用ID列举文档中的元素，并不关心元素的实
际意义和各元素彼此之间的关系。
一个ID类型属性值必须为有效的XML名称，该名称以字母开
头，由字母数字混排的字符和下划线组成，并且其中不带空
格。
ID类型属性与#FIXED类型的属性不兼容。
属性类型
（7）IDREF和IDREFS类型：
ID REFERENCE的意思，表明该属性的取值是对声明过
的一个ID型属性值的引用，也就是说，IDREF类型的值
必须匹配某些ID属性的值。
IDREFS类型表明该属性的取值是对声明过的多个ID型
属性值的引用，各ID值以空格分开。
例如：idref属性.xml；idref2属性.xml
属性类型
<?xml version = "1.0" encoding="GB2312“ standalone = "yes"?>
<!DOCTYPE 联系人列表[
<!ELEMENT 联系人列表 ANY>
<!ELEMENT 联系人(姓名,EMAIL)>
<!ELEMENT 姓名(#PCDATA)>
<!ELEMENT EMAIL(#PCDATA)>
<!ATTLIST 联系人 编号 ID #REQUIRED>
<!ATTLIST 联系人 上司 IDREF #IMPLIED>
]>
<联系人列表>
<联系人 编号="2">
<姓名>张三</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
<联系人 编号="1" 上司="2">
<姓名>李四</姓名>
<EMAIL>[email protected]</EMAIL>
</联系人>
</联系人列表>
综合举例
我们学习了元素、属性和内容类型的基本知识。下面提供通过例子，理解XML文档如
何道循DTD元素和属性表说明。
一个分类广告文档的DTD：文件名为output.dtd
<! ELEMENT AD (NEWSPAPER, (INCOLUMN|DISPLAY ) ) >
<!ENTITY ADTEXT SYSTEM “adText.txt” >
<!ATTLIST AD id ID #REQUIRED >
<!ELEMENT NEWSPAPER (#PCDATA)>
<!ELEMENT INCOLUMN (INCOLUMNSIZE, INCOLUMNCONTENT)>
<!ELEMENT INCOLUMNSIZE (#PCDATA)>
<!ELEMENT INCOLUMNCONTENT (#PCDATA)>
<!ATTLIST INCOLUMNSIZE lines NMTOKEN #REQUIRED >
<!ATTLIST INCOLUMNCONTENT width (1|2|3|4|5|6|7) #REQUIRED >
<!ELEMENT DISPLAY (DISPLAYSIZE, DISPLAYCONTENT)>
<!ELEMENT DISPLAYSIZE (#PCDATA)>
<!ELEMENT DISPLAYCONTENT (#PCDATA)>
<!ATTLIST DISPLAYSIZE lines NMTOKEN #REQUIRED >
<!ATTLIST DISPLAYCONTENT width (1|2|3|4|5|6|7) #REQUIRED >
综合举例
<?XML version=“1.0” standalone=“no” ?>
<!DOCTYPE AD SYSTEM “output.dtd”>
<AD id=“001”>
<NEWSPAPER> San Francisco Chronicle </NEWSPAPER>
<INCOLUMN>
<INCOLUMNSIZE lines=“50” width=“1”>
</INCOLUMNSIZE>
<INCOLUMNCONTENT>&ADTEXT;</INCOLUMNCONTENT>
</INCOLUMN>
</AD>
3.1.5 DTD的实体声明与引用
一般实体的声明与引用
–
声明：
–
引用
<!ENTITY 一般型实体名称 “实体代表的内容”>
&一般实体名称
参数型实体的声明和引用
–
声明：
–
–
<! ENTITY % 参数型实体名称 “实体代表的内容”>
特征：P49
示例：例3.3.dtd
3.1.5 DTD的实体声明与引用
正确声明和引用实体
1.
2.
3.
4.
一般型实体声明后，可在XML主体文档中被引用，这
包括在元素内容和在设置属性值时引用。一个一般型
实体的声明中被引用，但是不能在元素声明中被引用。
实体声明中引用实体时，不能形成死循环
参数型实体必须在外部DTD中进行声明，而不能在内
部DTD中声明。
在XML文档主体中只能引用一般型实体，引用参数型
实体并不能达到引用相应内容的效果