Draft of conformance clause for DITA 2.0

[robander]

Our DITA 1.x conformance clause was troublesome. It had 3 sections: implementations, documents, and grammar files. These sections were generally descriptive, providing some rules, and laying out a few new concepts and terminology related to conformance. Feedback from OASIS TAB indicated a strong preference for conformance clauses to (instead) be a clear list of rules that must be followed in order to conform with the specification, along with links to those rules.

This is a first draft of a conformance clause for DITA 2.0 which attempts to respond to the TAB comments:

1. For conformance of implementations, the draft is a list of core features, initially based on those in the DITA 1.3 architectural specification. There is still a recognition that "implementation" can mean many different things, thus not all features are relevant to all implementations. In order to conform, an implementation MUST follow the rules for any feature that it claims to support, as laid out in [link to topic].
2. For conformance of documents, I've suggested a new approach that provides categories of DITA documents. I think this is much clearer than what we have today, and will easily allow an implementer to determine if documents conform:
   -- If you use the OASIS grammar files, you must follow all rules in those files + descriptive rules for the elements in the spec. I took this approach from the DocBook conformance clause, which states "A conformant DocBook V5.1 document must be valid according to both the grammar and the assertions."
   -- If you use a custom document type shell, the shell must also follow the rules in [that section]. If the shell uses constraints, those must also follow the rules in [that section].
   -- If you use specialization, it must also follow the rules in [those sections].
3. For now, I've left out any section about conformance of grammar files, for two reasons. First - based on recent discussions, we're considering major changes here (RNG based delivery with no modular DTD/XSD), so it's clearly in flux. Second, how the grammar file is maintained has no impact on the conformance of DITA implementations or documents. More important, it has no impact on the interoperability of those implementations / documents.