1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
<?xml version="1.0" encoding="UTF-8"?>
<!--
@(#)testcases.dtd 1.0 12/18/00
Mary Brady, NIST
DTD describing a database of XSL tests.
Revised 2001 Jan 10 (Paul Grosso) - augmented by XSL FO SG:
- add to the TEST element an XSL attribute to point to
the XSL stylesheet and rename the URI attribute to XML
- add to the TEST element a PROPERTY attribute to
indicate when a given property is being tested
- add to the TEST element a LEVEL attribute to indicate
which conformance level is being tested
- add to the TEST element a SPECPTR attribute
(of URI type) to allow referring to relevant sections
of the XSL spec.
- add to the TEST element an ERRATUM attribute
(of CDATA type) to allow recording of an erratum
name/number that this test is meant to test.
- add to INTERACTION attribute value list MULTIPLE
and give it a default of NONE
- add to FO attribute value list MULTIPLE
- make the BASE attribute on TESTCASES #IMPLIED,
since it's not unreasonable for all the URI-type
attributes to be absolute
- add to the TEST element a RESULTS attribute to point
to, say, the PDF demonstrating the expected output
Revised 2001 Jan 10 (Paul Grosso) - added TESTRESULT structure
Revised 2001 Jan 24 (Paul Grosso) - lowercased names (though
not in comments, since that helps highlight them)
2001-02-19 (AntennaHouse) added repeatable-page-master-alternatives
conditional-page-master-reference region-before
region-after region-start region-end static-content
inline inline-container.
-->
<!ENTITY % URI "CDATA">
<!ENTITY % text "(#PCDATA | em | b | a)*">
<!--
The root element of the whole collection is TESTSUITE. While not
very different from TESTCASES, it must be distinguished due to
improper processing by IE5.
-->
<!ELEMENT testsuite ( testcases+ )>
<!ATTLIST testsuite
profile CDATA #IMPLIED
>
<!--
The root element of a collection should be "TESTCASES". It serves to
group a set of tests to be collectively identified as follows:
* PROFILE - name of test profile
* BASE - base directory in which tests for this collection reside;
allows tests to be found in many application instances.
-->
<!ELEMENT testcases (test | testresult | testcases)*>
<!ATTLIST testcases
profile CDATA #IMPLIED
base CDATA #IMPLIED
>
<!--
The body of each TEST element is its description as well as a
discussion of the expected results. The following attributes
must be specified for each test as follows:
* ID - unique test identifier
* INTERACTION - used later for categorizing tests
* FO - formatting object that is tested
* XML - relative uri that points to the XML of the actual test
* XSL - relative uri that points to the XSL of the actual test
Other optional attributes are:
* PROPERTY - indicates the property being tested
* LEVEL - indicates which conformance level is being tested
* SPECPTR - pointer to relevant part of the XSL spec
* ERRATUM-LBL - label/name of the erratum being tested
* ERRATUM-PTR - pointer to the erratum being tested
* RESULTS - pointer to a display of the expected results
-->
<!ELEMENT test %text;>
<!ATTLIST test
id ID #REQUIRED
interaction (none|area|writing|spacing|collapsing|multiple) "none"
fo (root|page-sequence|page-sequence-master|single-page-master-reference|
repeatable-page-master-reference|repeatable-page-master-alternatives
|layout-master-set|conditional-page-master-reference|simple-page-master|
region-body|region-before|region-after|region-start|
region-end|static-content|inline | inline-container |
declarations|flow|block|block-container|bidi-override|
character|initial-property-set|external-graphic|leader|page-number|
table-and-caption|table|table-column|table-header|table-body|table-row|
table-cell|list-block|list-item|list-item-body|list-item-label|multi-case|
wrapper|multiple) #REQUIRED
xml %URI; #REQUIRED
xsl %URI; #REQUIRED
property CDATA #IMPLIED
level (basic|extended|complete) "basic"
specptr %URI; #IMPLIED
erratum-lbl CDATA #IMPLIED
erratum-ptr %URI; #IMPLIED
results %URI; #IMPLIED
>
<!--
Really basic HTML font tweaks, to support highlighting
some aspects of test descriptions ...
EM == emphasis (e.g. italics, fun colors)
B == bold
-->
<!ELEMENT em (#PCDATA | b)*>
<!ELEMENT b (#PCDATA | em)*>
<!--
We also allow for hyperlinks in text (e.g., to include
references to supporting evidence within SPECPROBLEM and
TESTPROBLEM).
-->
<!ELEMENT a (#PCDATA | b | em)*>
<!ATTLIST a
href %URI; #REQUIRED
>
<!--
The TESTRESULT element is used to record test results.
It has a required ID attribute which identifies the TEST.
It has a required AGREEMENT attribute that indicates whether
the results are in full agreement with the expected
results as described in the TEST case or not.
The textual contents of the TESTRESULT element should describe
the results of the test and any issues or further information.
The target of the optional RESULTS attribute could be either some
PDF showing the results or any other arbitrary resource
describing/discussing the results.
The optional FUTURESUPPORT attribute is used to indicate
expected future support of the feature tested by this
test case.
The optional SPECPROBLEM attribute indicates if there is
any ambiguity or other problem found in the spec that relates
to this test. Especially if the results weren't as expected
because of a misinterpretation of the spec, this should be
documented here. Details/discussion should appear in the
textual contents of the TESTRESULT element.
The optional TESTPROBLEM attribute indicates if there is
any issue with the TEST case and the expected results it
suggests. Especially if the results of the test differ
from that given as "expected" by the test case but are,
in fact, believed to be the correct results, this should
be documented here. Details/discussion should appear in the
textual contents of the TESTRESULT element.
-->
<!ELEMENT testresult %text;>
<!ATTLIST testresult
id CDATA #REQUIRED
agreement (full|issues) #REQUIRED
results %URI; #IMPLIED
futuresupport (full|partial|none) #IMPLIED
specproblem (yes|no) "no"
testproblem (yes|no) "no"
>
|
