Conformance to Markup Compatibility Is not defined.

Define conformance to Markup Compatibility. It probably shouldn’t be purely syntactical. Moreover, it might be necessary to separate OPC engines and OPC application programs.

Part 5

te

Proposed Disposition of DIS 29500 Comment JP-0080 (Modified: 2007-12-20) Agreed; we will make the following changes: 1. Add the following new clause to Part 5: 2. Conformance The text in this Part is divided into normative and informative categories. Unless documented otherwise, any feature shall be implemented as specified by the normative text describing that feature in this Part. Text marked informative (using the mechanisms described in §6, “General Description”) is for information purposes only. Unless stated otherwise, all text is normative. Use of the word “shall” indicates required behavior. Any behavior that is not explicitly specified by this Part is implicitly unspecified (Part 1, §4). Each Part of this multi-part standard has its own conformance clause. The term conformance class is used to disambiguate conformance within different Parts of this multi-part standard. This Part has only one conformance class, MCE (that is, Markup Compatibility and Extensibility). As such, conformance to that class implies conformance to the whole Part. 2.1. Document Conformance A document has conformance class MCE if it satisfies the syntax constraints on elements and attributes defined in this Part. Document conformance to this Part is purely syntactic. 2.2. Application Conformance An application implementing this Part has conformance class MCE if any one of the following is true: The application is a markup consumer that does not reject any documents of conformance class MCE; or The application is a markup producer that is able to produce documents of conformance class MCE; or The application is a markup editor that does not reject any documents of conformance class MCE, and is able to produce documents of conformance class MCE. Application conformance to this Part is purely syntactic. [Note: Application conformance to this Part cannot be based on semantics, since the semantics depend on the choice of application-defined extension elements. end note] 2. Modify Part 5, §6, “General Description,” page 7, lines 2–20, as follows: This specification is intended for use by implementers, academics, and application programmers. As such, it contains a considerable amount of explanatory material that, strictly speaking, is not necessary in a formal specification. This specification is divided into the following subdivisions: 1. Front matter (clauses 1­ 7 8 ); 2. Overview and introductory material (clause 8 9 ); 3. Main body (clauses 9­13 10-14 ); 4. Annexes Examples are provided to illustrate possible forms of the constructions described. References are used to refer to related clauses. Notes are provided to give advice or guidance to implementers or programmers. The following clauses form the normative pieces of this specification: Clauses 1­ 4 5 , 6 7 , and 8­11 9­12 The following clauses form the informative pieces of this specification: Introduction Clause 5 6 , 7 8 , and 12 13 All annexes All notes and examples Whole clauses that are informative are identified as such. Informative text that is contained within normative text is identified as either an example or note, as specified in §4. Except for whole clauses or annexes that are identified as being informative, informative text that is contained within normative text is indicated in the following ways: 1. [Example: code fragment, possibly with some narrative ... end example] 2. [Note: narrative ... end note] 3. [Rationale: narrative ... end rationale] 4. [Guidance: narrative ... end guidance]