Input: [#] 1085 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-20 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Complex type of which {content type} is a simple type


Input: [#] 1086 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-21 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Complex type of which {content type} is a particle


Input: [#] 1087 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-22 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Complex type of which {content type} is empty


Input: [#] 1088 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-23 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Complex type of which {content type} is a particle


Input: [#] 1089 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-24 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of xsi:type in a full-fledged complex type grammar


Input: [#] 1090 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-25 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use AT(goo:*) where both AT(xsi:type) and AT(xsi:nil) are available.


Input: [#] 1091 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-26 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of xsi:nil in a full-fledged complex type grammar


Input: [#] 1092 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-27 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use AT(goo:*) where there are no attribute uses available


Input: [#] 1093 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexTypeGrammar | schemaInformed.declared.complexType-28 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Attribute uses that use local attributes. AT(aK) is typed as xsd:positiveInteger, whereas AT(foo:aK) is typed as xsd:date.


Input: [#] 1094 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests AT(*) with two attributes one of which is globally declared and the other not declared.


Input: [#] 1095 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests AT(*) with an globally defined attribute that has an invalid value.


Input: [#] 1096 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the semantics of xsi:type attribute.


Input: [#] 1097 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: xsi:type attribute with a value of which the prefix is not defined.


Input: [#] 1098 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: xsi:type attribute with a value that does not resolve to a type.


Input: [#] 1099 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the semantics of xsi:nil attribute.


Input: [#] 1100 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-08 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests SE(*) when it is matched by a non-declared element.


Input: [#] 1101 [Test case] | all | byteAlign | schemaInformed | declaredProductions | complexUrTypeGrammar | schemaInformed.declared.complexUrType-09 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests SE(*) when it is matched by a globally declared element.


Input: [#] 1102 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the element wildcard matched


Input: [#] 1103 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 1st element declaration matched


Input: [#] 1104 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 2nd element declaration matched


Input: [#] 1105 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 3rd element declaration matched


Input: [#] 1106 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 4th element declaration matched


Input: [#] 1107 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 5th element declaration matched


Input: [#] 1108 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedDocumentGrammar | schemaInformed.declared.document-07 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of document grammar with the 6th element declaration matched


Input: [#] 1109 [Test case] | all | byteAlign | schemaInformed | declaredProductions | duplicateTerminals | schemaInformed.declared.duplicateTerminals-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the ability to eliminate duplicate terminal symbols. Inner loop is stateful.


Input: [#] 1110 [Test case] | all | byteAlign | schemaInformed | declaredProductions | duplicateTerminals | schemaInformed.declared.duplicateTerminals-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the ability to eliminate duplicate terminal symbols. Outer loop is stateful.


Input: [#] 1111 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedElementGrammar | schemaInformed.declared.element-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Element declaration that uses a named type as its type definition


Input: [#] 1112 [Test case] | all | byteAlign | schemaInformed | declaredProductions | informedElementGrammar | schemaInformed.declared.element-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Element declaration that uses a anonymous type as its type definition


Input: [#] 1113 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests AT(qname) and AT(*) event types, and the typed encodings of attributed values. The values of AT(foo:c) and AT(foo:d) should be represented as strings because not all definitions of each are not identical.


Input: [#] 1114 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests SE(qname), SE(*) and CH event types. The elements in namespace urn:aoo and urn:goo use their specific grammars, while the elements in namespace urn:foo use the element fragment grammar.


Input: [#] 1115 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests ElementFragmentTypeEmpty grammar. The attributes in namespace urn:aoo use their specific datatype representation, while the attributes in namespace urn:foo use string representation.


Input: [#] 1116 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests xsi:type attribute semantics.


Input: [#] 1117 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests CM and PI in element fragment grammar.


Input: [#] 1118 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementFragmentGrammar | schemaInformed.declared.elementFragment-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests CM and PI in element fragment grammar when xsi:nil='true'.


Input: [#] 1119 [Test case] | all | byteAlign | schemaInformed | declaredProductions | elementTermGrammar | schemaInformed.declared.elementTerm-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Substitution group test


Input: [#] 1120 [Test case] | all | byteAlign | schemaInformed | declaredProductions | eventCodeAssignment | schemaInformed.declared.eventCodeAssignment-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the assignment of event codes.


Input: [#] 1121 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the production order in fragment grammars. 1st part of event codes should take 4 bits when pis and comments are both preserved.


Input: [#] 1122 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests the production order in fragment grammars. 1st part of event codes should take only 3 (instead of 4) bits when neither pis nor comments are preserved.


Input: [#] 1123 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: There are 3 declarations of the element name 'foo:A' all of which use the same type. The same is true for the element name 'foo:B'.


Input: [#] 1124 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: There are 5 declarations of the element name 'foo:A' the types of which vary. The same is true for the element name 'foo:B'.


Input: [#] 1125 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: There are 3 declarations of the element name 'foo:A' all of which use the same type but with different nillability. The same is true for the element name 'foo:B'.


Input: [#] 1126 [Test case] | all | byteAlign | schemaInformed | declaredProductions | fragment | schemaInformed.declared.fragment-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: There are 3 declarations of the element name 'foo:A' all of which use the same type with the same nillability 'true'. The same is true for the element name 'foo:B'.


Input: [#] 1127 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 0 occurrences of an element particle that has (minOccurs,maxOccurs) of (0,3)


Input: [#] 1128 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 3 occurrences of an element particle that has (minOccurs,maxOccurs) of (0,3)


Input: [#] 1129 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 5 occurrences of an element particle that has (minOccurs,maxOccurs) of (0,unbounded)


Input: [#] 1130 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 2 occurrences of a sequence particle that has (minOccurs,maxOccurs) of (2,2)


Input: [#] 1131 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 2 occurrences of a sequence particle that has (minOccurs,maxOccurs) of (2,5)


Input: [#] 1132 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 5 occurrences of a sequence particle that has (minOccurs,maxOccurs) of (2,5)


Input: [#] 1133 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-07 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 6 occurrences of a sequence particle that has (minOccurs,maxOccurs) of (2,unbounded)


Input: [#] 1134 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-08 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 0 occurrences of a choice particle that has (minOccurs,maxOccurs) of (0,3)


Input: [#] 1135 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-09 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 3 occurrences of a choice particle that has (minOccurs,maxOccurs) of (0,3)


Input: [#] 1136 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-10 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 5 occurrences of a choice particle that has (minOccurs,maxOccurs) of (0,unbounded)


Input: [#] 1137 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-11 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 2 occurrences of a choice particle that has (minOccurs,maxOccurs) of (2,2)


Input: [#] 1138 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-12 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 2 occurrences of a choice particle that has (minOccurs,maxOccurs) of (2,5)


Input: [#] 1139 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-13 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 5 occurrences of a choice particle that has (minOccurs,maxOccurs) of (2,5)


Input: [#] 1140 [Test case] | all | byteAlign | schemaInformed | declaredProductions | particleGrammar | schemaInformed.declared.particle-14 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 6 occurrences of a choice particle that has (minOccurs,maxOccurs) of (2,unbounded)


Input: [#] 1141 [Test case] | all | byteAlign | schemaInformed | declaredProductions | sequenceGrammar | schemaInformed.declared.sequence-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 'sequence' instance with optional particles present


Input: [#] 1142 [Test case] | all | byteAlign | schemaInformed | declaredProductions | sequenceGrammar | schemaInformed.declared.sequence-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: 'sequence' instance with optional particles omitted


Input: [#] 1143 [Test case] | all | byteAlign | schemaInformed | declaredProductions | simpleTypeGrammar | schemaInformed.declared.simpleType-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH in Simple Type Grammar where CH matches a non-empty string


Input: [#] 1144 [Test case] | all | byteAlign | schemaInformed | declaredProductions | simpleTypeGrammar | schemaInformed.declared.simpleType-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH in Simple Type Grammar where CH matches an empty string


Input: [#] 1145 [Test case] | all | byteAlign | schemaInformed | declaredProductions | simpleTypeGrammar | schemaInformed.declared.simpleType-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of TypeEmpty in Simple Type Grammar


Input: [#] 1146 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | schemaInformed.declared.wildcard-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: use of ##other wildcard and specified non-default namespace wildcard


Input: [#] 1147 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | schemaInformed.declared.wildcard-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: use of ##other wildcard and specified default namespace wildcard


Input: [#] 1148 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | schemaInformed.declared.wildcard-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: use of specified non-default namespace wildcard


Input: [#] 1149 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | schemaInformed.declared.wildcard-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of ##any wildcard


Input: [#] 1150 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | schemaInformed.declared.wildcard-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of wildcards in a context with structures


Input: [#] 1151 [Test case] | all | byteAlign | schemaInformed | declaredProductions | wildcardTermGrammar | initialEntries | schemaInformed.declared.wildcard-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: URIs in specified namespace wildcards get in uri partition of the string table


Input: [#] 1152 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.attruseUntyped-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests undeclared attribute uses (i.e. AT(qname) [untyped value])


Input: [#] 1153 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.attrWildcard-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests undeclared AT(*).


Input: [#] 1154 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.attrWildcard-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests undeclared AT(*) [untyped value] using declared attributes with invalid values.


Input: [#] 1155 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.attrWildcard-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests undeclared AT(*) [untyped value] using non-declared attributes.


Input: [#] 1156 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ch-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH [untyped value] event at the start of an element


Input: [#] 1157 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ch-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH [untyped value] event before any element-content starts


Input: [#] 1158 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ch-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH [untyped value] event before any declared element-content starts


Input: [#] 1159 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ch-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of CH [untyped value] event in element-content-only context


Input: [#] 1160 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.cm-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests CM where there is no declared attributes or declared attribute wildcard.


Input: [#] 1161 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.cm-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests CM where there is a declared attribute.


Input: [#] 1162 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.cm-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests CM where there's a declared attribute wildcard.


Input: [#] 1163 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event where simple-type content is expected as well as required to appear


Input: [#] 1164 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event at the beginning of an element where at least one element is expected as well as required to appear


Input: [#] 1165 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event after xsi:type where at least one element is expected as well as required to appear


Input: [#] 1166 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event after xsi:type and xsi:nil where at least one attribute is expected as well as required to appear


Input: [#] 1167 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event in the middle of complex-content where at least one element is expected as well as required to appear


Input: [#] 1168 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.ee-06 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Use of end-of-element event in the middle of simple-content where simple-type content is expected as well as required to appear


Input: [#] 1169 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.er-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests ER where there is no declared attributes or declared attribute wildcard.


Input: [#] 1170 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.er-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests ER where there is a declared attribute.


Input: [#] 1171 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.er-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests ER where there's a declared attribute wildcard.


Input: [#] 1172 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.namespaceDecl-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests NS event type. NS events come before xsi:type attribute.


Input: [#] 1173 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.namespaceDecl-02 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests NS event type. Nested elements with namespace declarations.


Input: [#] 1174 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.namespaceDecl-03 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests NS event type. Nested elements with namespace declarations, where two or more prefixes are assigned to the same URI.


Input: [#] 1175 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.namespaceDecl-04 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests NS event type. xsi:nil attribute with two corresponding namespace declarations.


Input: [#] 1176 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.namespaceDecl-05 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests NS event type. xsi:type attribute with two corresponding namespace declarations.


Input: [#] 1177 [Test case] | all | byteAlign | schemaInformed | addingProductionsDefault | schemaInformed.undeclared.pi-01 [3 to 1] PASSED [2 to 1] PASSED [3 to 2] PASSED [1 to 2] PASSED [2 to 3] PASSED [1 to 3] PASSED [Specification reference] specification [Input file] file [Testcase description]

Output: Tests PI where there is no declared attributes or declared attribute wildcard.


Input: [General tool] HTML to Text converter [,shortcut] ,text [Access control] Same as the document [For this page]

Output: A plain text version of the page, handy for pasting into email.


Input: [General tool] Link Checker [,shortcut] ,checklink [Access control] Same as the document [For this page]

Output: List of bad links in the page


Input: [General tool] Link Checker [,shortcut] ,rchecklink [Access control] Same as the document [For this page]

Output: Bad links in a page and in pages linked from it


Input: [General tool] HTML Validator [,shortcut] ,validate [Access control] Same as the document [For this page]

Output: List of HTML markup errors.


Input: [General tool] W3C Spellchecker [,shortcut] ,spell [Access control] Same as the document [For this page]

Output: List of spelling errors.


Input: [General tool] CSS Validator [,shortcut] ,cssvalidate [Access control] Works only on public pages. [For this page]

Output: List of style CSS errors.


Input: [General tool] CVS Log [,shortcut] ,cvslog [Access control] Public on dev.w3.org, Team-only on www.w3.org [For this page]

Output: Log of changes to the document


Input: [General tool] Headers [,shortcut] ,headers [Access control] Same as the document [For this page]

Output: HTTP headers sent by the server


Input: [General tool] the pubrules checker [,shortcut] ,pubrules [Access control] Same as the document [For this page]

Output: Check the compliance of this document to the W3C publication rules


Input: [General tool] the pubrules checker [,shortcut] ,pubruleserrors [Access control] Same as the document [For this page]

Output: Check the compliance of this document to the W3C publication rules, only displaying errors


Input: [ID] 4 [Commenter] Detlev Fisher [Location] 3.1.4 Step 1.d: Define the Context of Website Use- Requirement 1.d [Status] Closed [Priority] Medium [Current Text] "...noting that the definition of software support shall not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for Accessibility Support." [Rationale] The term "software support" is undefined [Resolution]

Output: Resolution: Change text to: "...noting this definition shall not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for Accessibility Support." Rationale: No need to coin new definitions.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012

Listing of the comments for Section 3 - Conformance Evaluation Procedure and their proposed resolutions


Input: [ID] 5 [Commenter] Detlev Fisher [Location] 3.1.4 Step 1.d: Define the Context of Website Use- Requirement 1.d [Status] Closed [Priority] Medium [Current Text] "...noting that the definition of software support shall not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for Accessibility Support." "It is often not feasible for websites to support accessibility on every combination of web browser, assistive technology, and operating system that they run on, nor is it possible to test with every such combination of tools." [Rationale] There is a lack of guidance on how to define the minimum set of web browsers and assistive technology [Resolution]

Output: Resolution: Open an issue on "defining tools support" and with a link to this comment by Detlev Rationale: This issue needs a lot of thought and discussion, and could be one of the refinements in an upcoming draft.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 6 [Commenter] Detlev Fisher [Location] 3.1.4 Step 1.d: Define the Context of Website Use- Requirement 1.d [Status] Closed [Priority] Medium [Current Text] "It is often not feasible for websites to support accessibility on every combination of web browser, assistive technology, and operating system that they run on, nor is it possible to test with every such combination of tools." [Rationale] the term "tools" is ambiguous [Resolution]

Output: Resolution: Open an issue to "revise use of the term 'tools'" to discuss further with EOWG Rationale: Unclear if replacing every occurrence of "tools" with "user agents and assistive technologies" in this section will add clarity vs complexity.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 7 [Commenter] Detlev Fisher [Location] 3.1.4 Step 1.d: Define the Context of Website Use- Requirement 1.d [Status] Closed [Priority] Medium [Current Text] "It is often not feasible for websites to support accessibility on every combination of web browser, assistive technology, and operating system that they run on, nor is it possible to test with every such combination of tools." [Rationale] Suggest a minimum baseline of web browsers [Resolution]

Output: Resolution: No change for now. Rationale: This is not applicable to all evaluation contexts but maybe the guidance from comment ID5 could partially address this comment.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 8 [Commenter] Detlev Fisher [Location] 3.1.4 Step 1.d: Define the Context of Website Use- Requirement 1.d [Status] Closed [Priority] Medium [Current Text] "...noting that the definition of software support shall not conflict with the WCAG 2.0 guidance on the Level of Assistive Technology Support Needed for Accessibility Support." "It is often not feasible for websites to support accessibility on every combination of web browser, assistive technology, and operating system that they run on, nor is it possible to test with every such combination of tools." [Rationale] Require that the defined set of assistive technology are used comprehensively throughout the evaluation [Resolution]

Output: Resolution: No change. Rationale: This is emphasized in the third paragraph of this section and in the first of section 3.4.1

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 9a [Commenter] Richard Warren and Kerstin Probiesch (in questionnaire) [Location] 3.1.5 Step 1.e: Define the Techniques to be Used (Optional) [Status] Closed [Priority] High [Current Text] Entire section [Suggested Change] This section requires completely rewriting to make it clear we are talking about the evaluation techniques not the web-design techniques. [Rationale] This heading suggests that I will find information about the techniques that the evaluator expects to use during his/her evaluation. (I.E –robots to evaluate HTML and CSS code, toolbar to evaluate semantic structure on a page-by-page basis, screen-reader to confirm that audio output matches visual output. Etc..). Instead I find reference to the recommended techniques that a developer should use to build a compliant site.. At this stage of the evaluation process we have not even explored the site – so there is no way of knowing which "recommended techniques" have been used. Also remove the link to WCAG 2.0 Techniques. [Resolution]

Output: Resolution: Link the first occurrence of the term "techniques" to http://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-layers-techs-head, to clarify what is meant by this term. Rationale: There seems to be a confusion about the meaning of the term "techniques". The concept of "techniques" in WCAG 2.0 applies for evaluators and developers - they are ways for checking the complaince to Success Criteria.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 9b [Commenter] Richard Warren and Kerstin Probiesch (in questionnaire) [Location] 3.1.5 Step 1.e: Define the Techniques to be Used (Optional) [Status] Closed [Priority] High [Current Text] Entire section [Suggested Change] Describe the various tools and techniques that will be employed when conducting this evaluation. [Rationale] This heading suggests that I will find information about the techniques that the evaluator expects to use during his/her evaluation. (I.E –robots to evaluate HTML and CSS code, toolbar to evaluate semantic structure on a page-by-page basis, screen-reader to confirm that audio output matches visual output. Etc..). Instead I find reference to the recommended techniques that a developer should use to build a compliant site.. At this stage of the evaluation process we have not even explored the site – so there is no way of knowing which "recommended techniques" have been used. Also remove the link to WCAG 2.0 Techniques. [Resolution]

Output: Resolution: No change. Rationale: Listing individual tools limits the applicability of the methodology in different situations (e.g. different languages) and adds dependencies that make it difficult to maintain.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 9c [Commenter] Richard Warren and Kerstin Probiesch (in questionnaire) [Location] 3.1.5 Step 1.e: Define the Techniques to be Used (Optional) [Status] Closed [Priority] High [Current Text] Entire section [Suggested Change] This section [...] should not be optional. [Rationale] This heading suggests that I will find information about the techniques that the evaluator expects to use during his/her evaluation. (I.E –robots to evaluate HTML and CSS code, toolbar to evaluate semantic structure on a page-by-page basis, screen-reader to confirm that audio output matches visual output. Etc..). Instead I find reference to the recommended techniques that a developer should use to build a compliant site.. At this stage of the evaluation process we have not even explored the site – so there is no way of knowing which "recommended techniques" have been used. Also remove the link to WCAG 2.0 Techniques. [Resolution]

Output: Resolution: No change. Rationale: The concept of "techniques" in WCAG 2.0 are non-exclusive and thus non-normative - the compliance applies to the Success Criteria.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 10 [Commenter] Kathleen Wahlbin (in questionnaire) [Location] 3.1.5 Step 1.e: Define the Techniques to be Used (Optional) [Status] Closed [Priority] Medium [Suggested Change] Add information about sufficient vs advisory techniques [Rationale] This is an area that is confusing for people. Advisory techniques may not be fully supported by AT and should be noted in this section. If they are used, we should note that evaluators should make sure that they work with the web browsers and AT selected in step 3.1.4 Step 1d [Resolution]

Output: Resolution: Add "Note: Advisory techniques may not be fully supported by Assistive Technology. If they are used, make sure that these work with the web browsers and Assistive Technology selected in step 3.1.4 Step 1.d" in this section or in section 3.4.2 Step 4.b Rationale: This may be more applicable to the actual evaluation stage though some mention here may be useful too.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 11a [Commenter] Richard Warren (in questionnaire) [Location] 3.2 Step 2: Explore the Target Website [Status] Closed [Priority] High [Suggested Change] Separate 1st paraghraph into two [Rationale] The second and third sentence in the first paragraph of the introduction are helpful suggestions and not related directly to the first sentence or the main purpose of this step. Therefore they should form a new paragraph. [Resolution]

Output: Resolution: Change as suggested Rationale: The paragraph makes two distinct points

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 11b [Commenter] Richard Warren (in questionnaire) [Location] 3.2 Step 2: Explore the Target Website [Status] Closed [Priority] High [Suggested Change] Add "purpose" to the first sentence [Rationale] This first exploration of the website should also check/confirm the *purpose* of the site. This is the only time the evaluator will get a "first impression" so the word purpose (or similar) should be included [...] [Resolution]

Output: Resolution: Change as suggested Rationale: The purpose of the website should indeed be confirmed in this step

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 11c [Commenter] Richard Warren (in questionnaire) [Location] 3.2 Step 2: Explore the Target Website [Status] Closed [Priority] High [Suggested Change] Remove "as candidates for selection in the sampling step defined in 3.3 Step 3: Select a Representative Sample" from the end of the 1st paragraph [Rationale] We agreed that the default position is to evaluate every page of the website as this is the only way to be 100% sure of the reliability of our result [...] [Resolution]

Output: Resolution: Change to "for more detailed evaluation later on" Rationale: Not crucial to relate this aspect to sampling Also see commment ID14

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 12 [Commenter] Martijn Houtepen (in questionnaire) [Location] 3.2 Step 2: Explore the Target Website [Status] Closed [Priority] Editorial [Current Text] Carrying out initial cursory checks during this stage already helps identify web pages that are relevant for more detailed evaluation later on. [Suggested Change] Carrying out initial cursory checks during this stage helps identify web pages that are relevant for more detailed evaluation later on. [Rationale] The word 'already' seems superfluous [Resolution]

Output: Resolution: Change as suggested Rationale: The word 'already' is superfluous

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 13a [Commenter] Detlev Fisher [Location] 3.2.1 Step 2.a: Identify Key Web Pages of the Website - Requirement 2.a [Status] Closed [Priority] Medium [Current Text] Entire section, possibly also other sections such as 3.3.1 Step 3.a [Suggested Change] Remove references to "template" [Rationale] I do not see why separating the template from the instance of the template would make sense [...] Most SC would need to be evaluated not in a 'dry run' but as instantiated web page [...] [Resolution]

Output: Resolution: Change as suggested in this and other sections where applicable, and add a note on identifying templates as an additional, optional part the sample Rationale: Currently the emphasis on "templates" seems too strong

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 13b [Commenter] Detlev Fisher Kathleen Wahlbin (in questionnaire) [Location] 3.2.1 Step 2.a: Identify Key Web Pages of the Website - Requirement 2.a [Status] Closed [Priority] Medium [Current Text] Entire section, possibly also other sections such as 3.3.1 Step 3.a [Suggested Change] Add "page states" [Rationale] I have added 'page states' as important parts of the sample [...] Page states is just as important as common webpages and templates [Resolution]

Output: Resolution: Add "including the states of a web page" with a link to the section on web applications where relevant Rationale: Important reminder that "web pages" includes each of its states

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 14 [Commenter] Richard Warren, Kerstin Probiesch, and Kathleen Wahlbin (in questionnaire) [Location] 3.3 Step 3: Select a Representative Sample [Status] Closed [Priority] High [Suggested Change] This section should be optional and requires an introductory paragraph to explain why sampling might be required. [Rationale] We have discussed this at length and agreed that a full audit (every page) should be the default position. Sampling should only be used if the site is large and resources are limited. If sampling is used it must be stated in the conformance claim. [Resolution]

Output: Resolution: Add a paragraph like "While ideally every web page of a website is evaluated, usually this is not possible on most websites. In cases where all web pages can be evaluated, this sampling procedure can be skipped and the selected sample is considered to be the entire website in the remaining steps." Rationale: Reiterate what is already explained in the section on small websites See also commment ID11c

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 17 [Commenter] Detlev Fisher Kathleen Wahlbin (in questionnaire) [Location] 3.3.2 Step 3.b: Include Exemplar Instances of Web Pages - Requirement 3b [Status] Closed [Priority] Medium [Current Text] Requirement 3.b: At least two distinct web pages (where applicable) of each (1) key functionality, (2) content, design, and functionality, and (3) web technologies shall be part of the selected sample of web pages. [Suggested Change] I would drop the requirement to have two distinct pages if what is meant is necessarily have two instances of page based on the same template. Instead I would put more emphasis than currently in evidence on exploring (and selecting, documenting) different *page states* (expanded menus, light boxes, tab panels, inserted error handling messages, etc) [Rationale] One page per feature may be fine if the pages are nearly identical in structure and content. I believe that it must be down to the site exploration and the actual variation found whether one, two or more pages should be selected. Following this rule strictly it would greatly increase the number of pages in the sample (and in turn, effort) often with only marginal benefits. [Resolution]

Output: Resolution: Open an issue to "Discuss number of webpages for requirement 3.b", and ask specifically for comments on this section when we publish the draft for public comments Rationale: This issue requires more thought and discussion

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 18 [Commenter] Detlev Fisher [Location] 3.3.4 Step 3.d: Include Complete Processes in the Sample [Status] Closed [Priority] High [Current Text] Requirement 3.d: All web pages that are part of a complete process shall be included. The selected sample must include all web pages that belong to a series of web pages presenting a complete process. Also, no web page in the selected sample may be part of a process without all other web pages that are part of that process to be also included into the selected sample. [Suggested Change] Add a note: "Note: Including all pages of a process in the selected sample is not necessary when process steps are repetitive and based on the same template. For example, an online questionnaire may lead the user through dozens of multiple choice questions, each containing four radio buttons and based on the same template. In such case, including one of these pages in the selected sample would be sufficient." [Rationale] Evaluating many near-identical process pages would be a waste of time. [Resolution]

Output: Resolution: No Change Resolution: To know this, it is necessary to do evaluation. Repetition is already covered in the Note in section 3.4 Step 4.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 19 [Commenter] Richard Warren and Kerstin Probiesch (in questionnaire) [Location] 3.4 Step 4: Audit the Selected Sample [Status] Closed [Priority] High [Current Text] Audit the Selected Sample [Suggested Change] Title should read 'Audit the site or the selected sample'. Change also every reference to this section in other sections. [Rationale] We agreed that full audits were the default position [Resolution]

Output: Resolution: No change Rationale: Several places throughout the document explain that the sample can be the entire website (see resolution for comment ID14). The suggested change to the title adds considerable complexity for fairly few situations.

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 20 [Commenter] Detlev Fisher [Location] 3.4 Step 4: Audit the Selected Sample - Note [Status] Closed [Priority] High [Current Text] Note at the end of the section [Suggested Change] All SC should be rated for all pages in the selected sample. Comments may be included just once and referenced from other places having the same issue. [Rationale] I would argue that the assessment of WCAG SC should be carried out for each page in the sample [...] [Resolution]

Output: Resolution: No change Rationale: 3.4 Step 4 already states: "WCAG 2.0 defines five conformance requirements that need to be met for each web page in the sample [...] This includes checking whether each WCAG 2.0 Success Criterion in the target conformance level [...] has been met or not met for each of these web pages"

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 21 [Commenter] Richard Warren (in questionnaire) [Location] 3.4 Step 4: Audit the Selected Sample - The penultimate sentence of the Note: for step 4 [Status] Closed [Priority] High [Current Text] evaluator may not need to continue to identify successes and failures in meeting the conformance target for each web page. [Suggested Change] Change to add phrase "repetitive elements" and read as follows: "evaluator may not need to continue to identify successes and failures in meeting the conformance target for these repetitive elements on every web page." [Rationale] The note refers to repetitive content. At present this sentence reads "evaluator may not need to continue to identify successes and failures in meeting the conformance target for each web page." This is a little ambiguous and could be taken to include none-repetitive content. [Resolution]

Output: Resolution: Change as suggested Rationale: Clarifies the intended meaning

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 22 [Commenter] Detlev Fisher Aurélien Levy (in questionnaire) [Location] 3.4 Step 4a: Check for the Broadest Variety of Use Cases - Requirement 4.a, Note 1 [Status] Closed [Priority] High [Current Text] Note: According to WCAG 2.0, Success Criteria that do not apply to the content are deemed to have been met. [Suggested Change] Note: While according to WCAG 2.0, Success Criteria that do not apply to the content are deemed to be satisfied, evaluators are free to set those Success Criteria to 'not applicable' since this differentiation can be highly meaningful for clients and other users of the evalution results. [Rationale] Whether WCAG-EM should include 'not applicable' as rating option has been discussed at length in a previous EVAL-TF teleconference and I remember there was a sound majority in favour of it. [Resolution]

Output: Previous resolution: Change note to read "Note: According to WCAG 2.0, Success Criteria that do not apply to the content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable", and add link to the definition of "satisfy" in WCAG2.0 Updated resolution: Further refine the note in response to WCAG WG Comment #19 to read "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable", and add link to the definition of "satisfy" in WCAG2.0 Rationale: Clarifies the use of terms such as 'Not Applicable'

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 24 [Commenter] Detlev Fisher [Location] 3.4 Step 4a: Check for the Broadest Variety of Use Cases - Requirement 4.a, Note 2 [Status] Closed [Priority] Medium [Current Text] Second Note (at the end of the section) [Suggested Change] "Many websites are based on templates. Evaluating one page based on a particular template can identify accessibility issues pertinent also to other pages based on the same template. When evaluating further pages based on the same template and the same template issue is found, Success Criteria ratings and comments may simply refer to other pages in the sample where the issue has already been covered." [Rationale] I do not see how one would evaluate the template on its own, instead of a particular instance with all content rendered as web page. Therefore I find the whole paragraph rather confusing. The point included in my suggested revision is different: cut out repetition if some issue has already been explained on another page in the sample. [Resolution]

Output: Resolution: Change note to "Templates are often used to create many web pages, sometimes entire parts a website. While evaluating templates is optional in this methodology, in some contexts it can be helpful to check templates on their own. Evaluating templates may identify potential issues that may not be easily identified through evaluating individual instances of web pages. However, issues identified in templates alone do not necessarily imply that these issues occur on the website and need to be validated on individual instances of web pages. Also, identifying no issues in templates does not necessarily imply that no issues occur on on individual instances of web pages" Rationale: Some of the previous references to templates are removed per comment ID13a, so that this note may become more valuable. Evaluating templates on their own helps understand how a website is contructed and identify potential issues that are not easy to identify otherwise. See discussion thread on "templates" and Minutes from 30 August Telco for change from "usually" to "often" in the resolution

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 25 [Commenter] Kerstin Probiesch and Aurélien Levy (in questionnaire) [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible [Status] Closed [Priority] High [Current Text] Use WCAG 2.0 Techniques Where Possible [Suggested Change] Use WCAG 2.0 Techniques test procedure Where Possible (optional) [Rationale] As 3.1.5 Step 1.e is optional this step must be optional too. Furthermore without making it optional some of current wcag evaluation methodology such as Accessiweb, RGAA, UWEM,etc will fail to conform to WCAG-EM [Resolution]

Output: Resolution: Add "(Optional)" to the current title Rationale: It is understood that the use of techniques is optional

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 26 [Commenter] Richard Warren (in questionnaire) [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible- Requirement 4.b [Status] Closed [Priority] High [Current Text] Requirement 4.b: "Where possible, WCAG 2.0 techniques shall be used to demonstrate successes and failures in meeting the WCAG 2.0 Success Criteria relevant per 3.1.3 Step 1.c: Define the Conformance Target." [Suggested Change] Requirement 4.b: "Where the correct use of appropriate WCAG 2.0 techniques can be identified they can be used to demonstrate successes in meeting the WCAG 2.0 Success Criteria." [Rationale] It is still not clear that if the evaluator can identify the correct use of WCAG techniques then these can be used by the evaluator as evidence of compliance. I suggest that the wording be changed. This means that the evaluator can confirm compliance if the appropriate technique has been correctly applied without having to do any other test. For example: if the label element has been applied to enclose both the field instruction and the input field then there is no need to check manually if the form progresses properly when using the keyboard or can work in forms mode with a screen reader. [Resolution]

Output: Resolution: Change to "Where possible, applicable WCAG 2.0 techniques shall be used to demonstrate successes and failures [...]" Rationale: "Common Failure" techniques can also be used to demonstrate *not* met Success Criteria

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 27 [Commenter] Kerstin Probiesch (in questionnaire) [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible- Requirement 4b [Status] Closed [Priority] High [Current Text] Requirement 4.b: Where possible, WCAG 2.0 techniques shall be used to demonstrate successes and failures in meeting the WCAG 2.0 Success Criteria relevant per 3.1.3 Step 1.c: Define the Conformance Target. [Rationale] This sentence is contrary to what is said in the techniques-intro of WCAG 2.0: "Test procedures do not, however, imply success or failure beyond the particular technique. In particular, test procedures for individual techniques should not be taken as test procedures for the WCAG 2.0 success criteria overall. " [Resolution]

Output: Resolution: No change Rationale: A single technique may not necessarily *imply* success or failure. However, techniques in general (plural) help *demonstrate* conformance (or failure)

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 28 [Commenter] Kerstin Probiesch (in questionnaire) [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible- Requirement 4b [Status] Closed [Priority] High [Current Text] In this case the evaluator must determine whether the WCAG 2.0 Success Criteria are met without the use of techniques. [Suggested Change] Rewrite the sentence and the section and make it optional. [Rationale] The sentence is unclear. Reason: there is no way to build a web page without using techniques. [Resolution]

Output: Previous resolution: Change to "In this case the evaluator must determine whether the WCAG 2.0 Success Criteria are met without the use of documented techniques." Previous rationale: Clarifies that we are refering to a particular use of the term 'techniques' (as per WCAG 2.0) Updated resolution: Comment addressed per changes in response to Comment #29 Updated rationale: The entire section has been rewritten so that particular comments is no longer applicable; however, the rationale of the comment has been principally accepted and integrated into the rewrite for the section

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 29 [Commenter] Detlev Fisher [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible- Requirement 4b, first bullet point [Status] Closed [Priority] Medium [Current Text] Second paragraph, including bullet list [Suggested Change] Complete rewording provided in the comment [Rationale] Several rationale provided in the comment [Resolution]

Output: Resolution: We added an editor note with brief description of what we are looking for to step 1e to ask for public review on this section and open an issue to discuss this issue further after publication. Note: See suggestion for editorial improvements to 3.1.5 Step 1.e and 3.4.2 Step 4.b Rationale: Comments mostly accepted but wording such as "evidence" have not been directly adopted as proposed. See for final decision: EvalTF minutes of 30 August 2012

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 30 [Commenter] Detlev Fisher [Location] 3.4.2 Step 4.b: Use WCAG 2.0 Techniques Where Possible- Requirement 4b, end of last but one paragraph [Status] Closed [Priority] Mild [Current Text] Otherwise it is good practice (for efficacy and justifiability) to use existing techniques to demonstrate successes and failures in meeting WCAG 2.0 Success Criteria. [Suggested Change] Delete the sentence. [Rationale] This is in substance a repetition of the intitial statement that (WCAG Techniques) "..provide an effective way of demonstrating whether WCAG 2.0 Success Criteria are met or not met." 'Justifiability' seems the wrong term - what is meant is that refering to the success or failure of using a WCAG Technique (established through its test) provides evidence for the conformance judgement of the evaluator. Also not sure whether referring to the matching WCAG Technique makes anything more 'efficacious' [...] [Resolution]

Output: Resolution: Removed as suggested Rationale: Agreement with the rationale provided Note: See also the changes to this sectuib in response to Comment #29

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 31 [Commenter] Richard Warren (in questionnaire) [Location] 3.4.3 Step 4.c: Assess Accessibility Support for Technologies - Requirement 4c [Status] Closed [Priority] High [Current Text] Each use of the web technologies used to create the web page content shall be checked to be accessibility supported by the tools defined in Step 1.d:. [Suggested Change] Change word 'create' to 'present' in the requirement statement as follows: "Requirement 4.c: Each use of the web technologies used to present the web page content shall be checked to be accessibility supported by the tools defined in Step 1.d:". [Rationale] We are not evaluating the tools etc used to create the site (e.g Dreamweaver, Joomla, Websphere etc). We are checking the technologies used to deliver the content to the user. For example if scripts are used to display content such as warnings (and we have note specified in step 1d that all users will have scripting enabled) will the content still display if scripting is not enabled ? [Resolution]

Output: Resolution: Changed as suggested Rationale: Clarifies the intended meaning

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [ID] 32 [Commenter] Aurélien Levy (in questionnaire) [Location] 3.5.2 Step 5.b: Provide an Accessibility Statement (Optional) [Status] Closed [Priority] High [Current Text] The website owner commits to removing any valid issues known to them within 10 business days; [Suggested Change] The website owner commits to give feedback on any valid issues known to them within 5 business days; This feedback should containt a detailed planning of remediation or an alternative way to get access to the information [Rationale] Why 10 days? In some situations it can take longer to get something fixed on some big corporate or ministerial website. [Resolution]

Output: Resolution: Changed to "The website owner commits to ensuring the accuracy and validity of the accessibility statement"; See current discussion thread on "accessibility statements". Also: Changed Accessibility Statement (Optional)" to " Provide an Accessibility Evaluation Statement @@@ According to this Methodology (Optional)" in 4 september 2012 Editor Draft. Rationale: Remediation action is beyond the scope of an evaluation methodology

Disposition of Comments from Eval TF Review - WCAG-EM Editor Draft 30 July 2012


Input: [Description] Updated to use the http://www.w3.org/2001/XMLSchema namespace [Class]

Output: Namespace


Input: [Description] Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-envelope [Class]

Output: Namespace


Input: [Description] Changed element and attribute wildcards in Envelope complex type to namespace="##other" [Class]

Output: Clarification


Input: [Description] Changed element and attribute wildcards in Header complex type to namespace="##other" [Class]

Output: Clarification


Input: [Description] Added explicit namespace="##any" to element and attribute wildcards in Body complex type [Class]

Output: Clarification


Input: [Description] Added explicit namespace="##any" to element and attribute wildcards in detail complex type [Class]

Output: Clarification


Input: [Description] Added an element wildcard with namespace="##other" to the Fault complex type [Class]

Output: Clarification


Input: [Description] Changed item type of encodingStyle from uri-reference to anyURI [Class]

Output: Name


Input: [Description] Changed type of actor attribute from uri-reference to anyURI [Class]

Output: Name


Input: [Description] Changed type of faultactor attribute from uri-reference to anyURI [Class]

Output: Name


Input: [Description] Added processContents="lax" to all element and attribute wildcards [Class]

Output: Semantic


Input: [Description] Changed type of the mustUnderstand attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed. [Class]

Output: Semantic


Input: [Description] Where possible comments have been changed into annotations [Class]

Output: Style


Input: [Description] Changed all occurences of maxOccurs="*" to maxOccurs="unbounded" [Class]

Output: Syntax


Input: [Description] Added to all complex type definitions derived implicitly from the ur-type [Class]

Output: Syntax


Input: [Description] Added to all named model group definitions [Class]

Output: Syntax


Input: [Notation] {$ rule text $} [Interpretation]

Output: Emit the rule text substituting any occurrence of variables from the binding map. The outer {$ $} can be omitted in cases where there is no ambiguity.


Input: [Notation] for(?elt in ?list) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.


Input: [Notation] for(?elt in ?list, != ?other) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn, skipping any element identical to ?other, replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.


Input: [Notation] $length(?list)$ [Interpretation]

Output: Used within a template this will be replaced by the length the RDFList bound to ?list.


Input: [Notation] $i$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt.


Input: [Notation] $i+1$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt, plus 1.


Input: [Event name] loadstart [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent begins looking for media data, as part of the resource selection algorithm. [Preconditions]

Output: networkState equals NETWORK_LOADING


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is fetching media data. [Preconditions]

Output: networkState equals NETWORK_LOADING


Input: [Event name] suspend [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded. [Preconditions]

Output: networkState equals NETWORK_IDLE


Input: [Event name] load [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent finishes fetching the entire media resource. [Preconditions]

Output: networkState equals NETWORK_LOADED


Input: [Event name] abort [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent stops fetching the media data before it is completely downloaded. [Preconditions]

Output: error is an object with the code MEDIA_ERR_ABORTED. networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending on when the download was aborted.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Dispatched when...] An error occurs while fetching the media data. [Preconditions]

Output: error is an object with the code MEDIA_ERR_NETWORK or higher. networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending on when the download was aborted.


Input: [Event name] emptied [Interface] Event [Dispatched when...] A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running, in which case it is fired synchronously during the load() method call). [Preconditions]

Output: networkState is NETWORK_EMPTY; all the DOM attributes are in their initial states.


Input: [Event name] stalled [Interface] ProgressEvent [Dispatched when...] The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. [Preconditions]

Output: networkState is NETWORK_LOADING.


Input: [Event name] play [Interface] Event [Dispatched when...] Playback has begun. Fired after the play() method has returned. [Preconditions]

Output: paused is newly false.


Input: [Event name] pause [Interface] Event [Dispatched when...] Playback has been paused. Fired after the pause method has returned. [Preconditions]

Output: paused is newly true.


Input: [Event name] loadedmetadata [Interface] Event [Dispatched when...] The user agent has just determined the duration and dimensions of the media resource. [Preconditions]

Output: readyState is newly equal to HAVE_METADATA or greater for the first time.


Input: [Event name] loadeddata [Interface] Event [Dispatched when...] The user agent can render the media data at the current playback position for the first time. [Preconditions]

Output: readyState newly increased to HAVE_CURRENT_DATA or greater for the first time.


Input: [Event name] waiting [Interface] Event [Dispatched when...] Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. [Preconditions]

Output: readyState is newly equal to or less than HAVE_CURRENT_DATA, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors.


Input: [Event name] playing [Interface] Event [Dispatched when...] Playback has started. [Preconditions]

Output: readyState is newly equal to or greater than HAVE_FUTURE_DATA, paused is false, seeking is false, or the current playback position is contained in one of the ranges in buffered.


Input: [Event name] canplay [Interface] Event [Dispatched when...] The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. [Preconditions]

Output: readyState newly increased to HAVE_FUTURE_DATA or greater.


Input: [Event name] canplaythrough [Interface] Event [Dispatched when...] The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. [Preconditions]

Output: readyState is newly equal to HAVE_ENOUGH_DATA.


Input: [Event name] ended [Interface] Event [Dispatched when...] Playback has stopped because the end of the media resource was reached. [Preconditions]

Output: currentTime equals the end of the media resource; ended is true.


Input: [Erratum] E1 [Bugzilla] 4372 [Description] This erratum places constraints on the type of string that is valid for the doctype-public attribute of xsl:output. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E2 [Bugzilla] 4557 [Description] This erratum corrects an editorial error concerning the number of phases of serialization. [Category]

Output: editorial

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E3 [Bugzilla] 5066 [Description] This erratum corrects an editorial error concerning the currently registered XHTML media types. [Category]

Output: editorial

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E4 [Bugzilla] 5433 [Description] This erratum clarifies how descendant elements of an XML island must be serialized according to the HTML output method. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E5 [Bugzilla] 5439 [Description] This erratum aligns the description of the effect of the include-content-type serialization parameter of the HTML output method with that of the XHTML output method. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E6 [Bugzilla] 5458 [Description] This erratum ensures that the sequence normalization process preserves any type annotations associated with nodes in the input sequence. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E7 [Bugzilla] 5300 [Description] This erratum clarifies how elements with empty content models are to be serialized under the HTML and XHTML output methods. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E8 [Bugzilla] 5441 [Description] This erratum ensures that Unicode normalization applies to all characters that might be adjacent in the serialized result produced by the text output method, including those that are in text nodes that are separated by element nodes in the data model instance. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E9 [Bugzilla] 5993 [Description] This erratum makes previously non-normative text that describes how the xhtml and html output methods must behave if the indent parameter has the value yes into normative text. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E10 [Bugzilla] 6466 [Description] This erratum specifies the syntactic constraints on the values of the doctype-public and doctype-system serialization parameters. [Category]

Output: substantive

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Erratum] E11 [Bugzilla] 6376 [Description] This erratum makes clear which parts of the recommendation are not considered to be normative. [Category]

Output: editorial

XSLT and XQuery Serialization 3.0 -- Review Version


Input: [Success Criteria] 3.2.1 On Focus (A) [Specific Benefits] This Success Criterion helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly. [Sufficient Techniques] Techniques for SC 3.2.1 [Description]

Output: When any component receives focus, it does not initiate a change of context.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.1 Error Identification (A) [Specific Benefits] Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred. This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues. [Sufficient Techniques] Techniques for SC 3.3.1 [Description]

Output: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.3 Error Suggestion (AA) [Specific Benefits] Providing information about how to correct input errors allows users who have learning disabilities to fill in a form successfully. Users who are blind or have impaired vision understand more easily the nature of the input error and how to correct it. People with motion impairment can reduce the number of times they need to change an input value. [Sufficient Techniques] Techniques for SC 3.3.3 [Description]

Output: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.4 Error Prevention (Legal, Financial, Data) (AA) [Specific Benefits] Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes. [Sufficient Techniques] Techniques for SC 3.3.4 [Description]

Output: For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: Reversible: Submissions are reversible. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.5 Help (AAA) [Specific Benefits] Assistance for text input helps individuals with writing disabilities and people with reading and intellectual disabilities who often have difficulty writing text in forms or other places that need text input. Additionally, these kinds of assistance help people who are aging and have the same difficulty in text input and/or mouse operation. [Sufficient Techniques] Techniques for SC 3.3.5 [Description]

Output: Context-sensitive help is available.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.6 Error Prevention (All) (AAA) [Specific Benefits] Providing safeguards to avoid consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes. [Sufficient Techniques] Techniques for SC 3.3.6 [Description]

Output: For Web pages that require the user to submit information, at least one of the following is true: Reversible: Submissions are reversible. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.2.1 On Focus (A) [Description] When any component receives focus, it does not initiate a change of context. [Sufficient Techniques] Techniques for SC 3.2.1 [Specific Benefits]

Output: This Success Criterion helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.1 Error Identification (A) [Description] If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. [Sufficient Techniques] Techniques for SC 3.3.1 [Specific Benefits]

Output: Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred. This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.3 Error Suggestion (AA) [Description] If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. [Sufficient Techniques] Techniques for SC 3.3.3 [Specific Benefits]

Output: Providing information about how to correct input errors allows users who have learning disabilities to fill in a form successfully. Users who are blind or have impaired vision understand more easily the nature of the input error and how to correct it. People with motion impairment can reduce the number of times they need to change an input value.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.4 Error Prevention (Legal, Financial, Data) (AA) [Description] For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: Reversible: Submissions are reversible. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission. [Sufficient Techniques] Techniques for SC 3.3.4 [Specific Benefits]

Output: Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.5 Help (AAA) [Description] Context-sensitive help is available. [Sufficient Techniques] Techniques for SC 3.3.5 [Specific Benefits]

Output: Assistance for text input helps individuals with writing disabilities and people with reading and intellectual disabilities who often have difficulty writing text in forms or other places that need text input. Additionally, these kinds of assistance help people who are aging and have the same difficulty in text input and/or mouse operation.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Success Criteria] 3.3.6 Error Prevention (All) (AAA) [Description] For Web pages that require the user to submit information, at least one of the following is true: Reversible: Submissions are reversible. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission [Sufficient Techniques] Techniques for SC 3.3.6 [Specific Benefits]

Output: Providing safeguards to avoid consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.

Accessibility By Roles - Analysis - WAI-Engage: Web Accessibility Community Group


Input: [Description] Applications can create alarms, notifying users [Source] SysApps Charter [Requirement]

Output: Alarm API

System Applications WG: Security Model - W3C Wiki


Input: [Description] Apps can add, remove and edit contacts [Source] SysApps Charter [Requirement]

Output: Contacts API

System Applications WG: Security Model - W3C Wiki


Input: [Description] Apps can send, receive and view SMS [Source] SysApps Charter [Requirement]

Output: Messaging API

System Applications WG: Security Model - W3C Wiki


Input: [Description] Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log [Source] SysApps Charter [Requirement]

Output: Telephony API

System Applications WG: Security Model - W3C Wiki


Input: [Description] Apps can create, manipulate and listen for low-level TCP and UDP connections [Source] SysApps Charter [Requirement]

Output: Raw Sockets API

System Applications WG: Security Model - W3C Wiki


Input: [Description] Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices [Source] SysApps Charter [Implications] The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model. [Requirement]

Output: Supports many device form factors

System Applications WG: Security Model - W3C Wiki


Input: [Description] All APIs defined by DAP should be accessible to system applications [Source] SysApps Charter [Implications] Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls [Requirement]

Output: DAP API Support

System Applications WG: Security Model - W3C Wiki


Input: [Description] Problems such as 'double prompting' should be avoided when integrating other APIs [Source] SysApps Charter [Implications] Some details of the expected user interactions may need to be specified in the security model or APIs [Requirement]

Output: Minimal user prompting

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications consist of HTML, CSS and JavaScript [Requirement]

Output: HTML5

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications have access to geolocation data [Requirement]

Output: Location

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications can communicate with other applications [Implications] Some kind of messaging will be supported [Requirement]

Output: Communicate with other applications

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications can communicate with pre-defined web addresses [Implications] Access remote domains will be possible [Requirement]

Output: Communicate with pre-defined endpoints

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications can run on any conformant platform, potentially including any device form factor [Source] Compatibility of application packages [Requirement]

Output: Valid across multiple platforms

System Applications WG: Security Model - W3C Wiki


Input: [Description] Allow access control decisions to be logged. [Source] webinos [Requirement]

Output: Access control log

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications shall be able to explain why access to data or APIs is being requested. [Source] webinos [Requirement]

Output: API access rationale

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications shall access only its specified device features, extensions and content. [Source] webinos [Requirement]

Output: Application capability restriction

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications shall specify its required functionality at install time or during updates. [Source] webinos [Requirement]

Output: Application intent

System Applications WG: Security Model - W3C Wiki


Input: [Description] Applications shall be isolated from each other. [Source] webinos [Requirement]

Output: Application isolation

System Applications WG: Security Model - W3C Wiki


Input: [Description] Changes to existing application intentions and permissions shall be approved by the end user. [Source] webinos [Requirement]

Output: Application policy approval

System Applications WG: Security Model - W3C Wiki


Input: [Description] Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime [Source] webinos [Requirement]

Output: Authenticity check

System Applications WG: Security Model - W3C Wiki


Input: [Description] The list of authorities that certified an application shall be viewable by end-users. [Source] webinos [Requirement]

Output: Certifier list

System Applications WG: Security Model - W3C Wiki


Input: [Description] The webinos runtime shall support the confidential storage of user credentials. [Source] webinos [Requirement]

Output: Confidential credentials storage

System Applications WG: Security Model - W3C Wiki


Input: [Description] Access to credentials storage shall be limited to a specific user, a specific device and a set of applications. [Source] webinos [Requirement]

Output: Credentials access restriction

System Applications WG: Security Model - W3C Wiki


Input: [Description] applications shall be able to explain how collected sensitive data will be managed. [Source] webinos [Requirement]

Output: Data management rationale

System Applications WG: Security Model - W3C Wiki


Input: [Description] A default security and privacy policy shall exist an be enforced on each conformant runtime [Source] webinos [Requirement]

Output: Default policy

System Applications WG: Security Model - W3C Wiki


Input: [Description] Personal devices shall be bound to their owner's identities. [Source] webinos [Requirement]

Output: Device-identity binding

System Applications WG: Security Model - W3C Wiki


Input: [Description] The binding between personal devices and owner's identity shall be revokable. [Source] webinos [Requirement]

Output: Device-identity binding revokation

System Applications WG: Security Model - W3C Wiki


Input: [Description] Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy. [Source] webinos [Requirement]

Output: Hierarchical policy enforcement

System Applications WG: Security Model - W3C Wiki


Input: [Description] Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites. [Source] webinos [Requirement]

Output: Secure cache

System Applications WG: Security Model - W3C Wiki


Input: [Description] Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities. [Source] webinos [Requirement]

Output: Secure storage

System Applications WG: Security Model - W3C Wiki