I'll try to defend my stance on validation of both tool and markup.

Here's a quote from the html spec for 4.0:

Lots of description of tool use here.

The browser presenting the html can surely be validated in how it does so as well as the html itself being validated against the DTD.

With UBL there is little point just describing the markup although an attempt has really been made to make conformance a matter of validity of an instance against the schema.

number as the invoice number element content I can't claim my app is compliant even though the instances will still validate. So UBL has a focus on saying the definitions of the elements are normative too.

I don't think a test suite can validate the content in those terms though apart from schema validity and maybe some calculation business rule validity too

This kind of illustrates that not only must the document be valid according to the spec in its structure but maybe with regard to its semantics (where there are normative rules, etc)

end user can be using the standard in a way which is valid or not. So the app has to test user input according to test assertions, say, and a test suite might test the app according to the same or other test assertions perhaps and the test suites can be tested using test assertions too.

Lots of tests and test assertions and layers and so on. If the standard is well written it will foster all of this to ensure best implementation and end user experience. A tall order though.