Conformance - Does not follow TC Process

5 Conformance reads:

*****
A conforming instance is an instance that does not violate any document constraints expressed by the schemas.

In addition, the following instance constraints that cannot be detected as schema constraints must not be violated:

every XML element that is not extension content is not allowed to be empty, and

the <

:PayloadContent> element is not allowed to have a combination of text and an element (that is, it must either be a non-empty string of text or it must be a single element).
*****

The TC Process (https://www.oasis-open.org/policies-guidelines/tc-process#specQuality) requires:

*****
(8) Conformance Clauses.

(8a) For Standards Track Work Products:

A specification that is approved by the TC at the Committee Specification Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof).
*****

Trivially there are no "numbered" conformance clauses but the substantive issue of not following the TC process goes much deeper.

I have not worked out all the permitted combinations but here are two different conformance targets:

Conformance Target 1, without extensions or digital signature.

Conformance Target 2, without extensions but with digital signature

Confomance Target 3, with extensions and digital signature

No doubt people more familiar with the draft can construct other, more specific conformance targets.

Specific conformance targets, as per the TC process, enables implementors to choose which features they will support and to create products based on those choices, while conforming to the OASIS standard.

For example, I might want to offer a product that DOES NOT support extensions but does OFFER digital signatures. How do I distinguish my conformance from that of a vendor that offers support for extensions but not digital signatures?

Moreover, how are consumers to judge the interoperability of applications that make different choices in their "conforming" to this standard?

At present, both implementers and consumers are left without any basis for judging interoperability between applications that claim conformance to this draft.