We conventionally think of schemas as being used as an exemplar pattern or contract between sender and receiver: standard schemas being perhaps the ultimate in this.
However there are also various kinds of limiting schemas: profile schemas where an industry or job group decide to subset the standard in some way, usage schemas where the schema is derived from the document set and lets you check whether a new document may have markup that has not been processed before, and an implementation schema, where the schema can be used to test documents that they only contain structures or values that can be accepted by a particular implementation of the standard schema.
What kind of limitations are we talking about? There are necessary limitations, such as the precision used for a calculation, which typically will not be specified in the standard. Then there are conforming limitations, which is where the standard specifies a typical behaviour or range of possible behaviours, which may include not accepting or stripping or ignoring some given element. Then there are non-conforming limitations, where an implementation does not accept some or all of some allowed value, or does the wrong thing with it. There are extension limitations, where the standard allows,some extensions but the implementation does no. And finally there are partial implementation limitations: for example where some element is accepted or generated or even round-tripped, but is not actually used: graceful degradation behaviour may fall into this category,
Schematron is well-suited to expressing these kinds of limitations.
The simple method for doing this is Schematron report element. For example,
<assert test="number(@width)" see="http://www.egstd.com/songXML.pdf;page=56"> A picture should have the width specified (in attribute width)
as a number.</assert>
<report test="@width > 100" role="limitation">
The implementation does not support widths greater than 100.
In this case, the assert element states the general constraint, but the report element (labelled with the role of "limitation" so that the validation message can be logged, routed or formatted appropriately by the user agent) says if the implementation limitation has been exceded.
Schematron has an attribute see which allows linking of constraints back to the original document.
Another approach would be to gather all the limitations for a simple product into a pattern. (Schematron's phase mechanism would be used to select the right pattern to test against, or to test the document against the limitations of multiple products at the same time by selecting multiple patterns.)
<title>Limitations of the product Brid on a Brae v1.0</title>
<report test="true()" role="limitation" diagnostics="terminal"
This file format is not supported on this old software.</assert>
<pattern id="BoaB3.1" >
<title>Limitations of the product Bird on a Wire v3.1</title>
<report test="count(verse) > 10" role="limitation" diagnostics="continue truncate">
The Brid on a Wire 3.1 software does not support more than 10 verses.
<diagnostic id="terminal">Unable to continue</diagnostic>
<diagnostic id="continue">Processing will continue as best as possible</diagnostic>
<diagnostic id="truncate">The material that cannot be processed will be removed</diagnostic>
You can see in that example there are two versions of the software: one pattern for an obsolete version just says "forget it", and one pattern for some other version which has a limitation in the number of elements it can handle. as before, the role attribute is used to label that the reports are "limitations" (you can use any keyword you like, to suit yourself: Schematron does not define particular roles).
The diagnostics attributes are used to select various subsidiary messages which concern practical issues: again the intent is to provide enough information declaratively that a back-end validation system can use. In this case I have also added a flag attribute: this sets a single label over the whole validation (i.e. in this case "unrecoverableError" is a label that is either present or absent as a validation outcome): this allows more specific control of the validation session, for example.
And the schema has the usual Schematron advantages: flat, declarative, powerful, open, human-friendly, and it fits into modern reporting systems (such as fatal/caution/warning/note systems).