In Fridsma's blog the use of "no optionality" is being applied in a very specific way. John Halamka likes to point out that when alternatives are part of a regulation, the result is that the vendor community must support all alternatives. Thus a this-or-that is actually a this-and-that. Thus an "or" is actually an "and". This is a good lesson to learn, as it really should get policy makers to think about what they are asking for. If they include optionality in regulation, they are actually mandating both. Meaning they are really not providing optional paths.
However optionality is a word that can be used in a different way, that should not be seen as a negative. Such as the "Consolidated CDA" is the basics of a document that must be fully specified a specific way without question; but if (optionality) you have Y or Z information you may (more optionality words) put them in the same document in this specific (not optional encoding) way. This extra information (Y or Z) is optional, but it isn't optional in the same way as is being reference with the OR-means-AND phrase. This extra information (Y or Z) is optional because it may or may-not have been captured or be relevant to the current context. It is optional because it is not minimally necessary for the broad use of the document; but if you have it then it is not optional on how to encode it. This is understood by most who are involved with standards daily, but confusing to those that look at it only once a month.
I believe that ONC is struggling with how to handle Direct vs Exchange. They had the big struggle between the Powerteam and the community pushback. They really want to push 'either', but know that the OR-means-AND rule; forces even the littlest vendor or organization to implement both. They are not worried about the big guys (big vendors or big organizations). The big guys have money, resources, and IT knowhow. So they struggle with how to mandate ONE, while making sure that the other is operationally acceptable. Given their focus on helping the little guy vs not caring about the big guy; they are more likely to continue to only mandate Direct. There is little question that for the little guy that Direct is the best stepping stone. But as Doug Fridsma points out in his blog:
The Modular Specifications project has identified two ways to transport information and has created more modular, substitutable specifications. Utilizing Direct specifications as the foundation, the project has created a Secure Transport specification based on SMTP and S/MIME and XDR and XDM Conversions. A second approach leverages Exchange specifications as a basis, and a Web services approach has been specified as SOAP over HTTP. From the multiple transport standards, two building blocks are now part of our standards portfolio.I might point out that they have more in-common that not One Metadata Model - Many Deployment Architectures