In the new paradigm of contract first designs for services a lot of it revolves around exposing a contract that defines the operations and messages for a service. In terms of Web Services (or WCF exposed via a web service) this also means exposing the schemas via the WSDL so that consumers know the inputs and outputs for that service and its methods.
This is my big question: When working with NIEM how many are exposing their subset schemas to their web services and how many are using a generic "Package as string" approach where the package details are agreed upon outside the context of your service?
I have seen this done both ways and recently have chosen to follow one direction. In my most recent service adventure I modeled my messages to contain some required input parameters (need to know who is making the request and for what agency) and in my return message I have the generic "Package as string" where the package is going to be this very large collection of documents formatted in NIEM.
Returning "Package as string" is very ambiguous and will make a few people cringe or sneer when (if) they read this. But there is a reason for this and it's two fold:
1) In terms of Interop there are several technologies out there that do not support mulitple imported schemas in a WSDL and they also do not support substitutions via the WSDL. (Noting that currently interop is not a major concern for my service but that does not mean I shouldn't be prepared for it).
2) Imposing that any consumers must deserialize or validate that structure upon receipt. This one really gets into the realm of performance. Deserialization is an expensive process and so is schema validation and imposing that on a client could cause performance issues.
The disconnect in the contract will be that consumers will have to validate (if they choose to) the message against the schema post receipt. This obviously has the consequence that if somehow the service returns an invalid message package than the consumer has to make a subsequent request to get a valid package. So, in effect, that also would be a performance hit. Far less likely to happen (yes, I trust my service) but it could.
In other exchanges not exposing the full NIEM / Justice XML schema subset via the service has been the norm. The schemas are handled outside the context of the actual receiving of a message from ther service(s) involved.
During one project the weakness was thought to be in .NET; ironically it turns out .NET far better support for schemas in WSDL than others. Which does illustrate Microsofts great adoption of XML and all it's related technologies.