In a request, digir.xsd v. 1.0, the <destination> object
has "resource" as an optional attribute, but providers
are implicitly(?) required(?) to return a diagnostic
condition if no resource is provided. The sourceforge
PHP provider returns the same fault, <diagnostic
code="RESOURCE_NOT_FOUND" severity="error"> as if a
resource is specified but is not available on the provider.
The difference in the diagnostic in this case lies only in
the human-targeted, schema-optional, string content of
However, the first condition apparently represents a
syntax error in the request and should be distinguished
from the case where a complete request is in fact for a
resource that is not found. Otherwise, an integrating
application can not easily determine that a programming
fault, instead of a data error, is in play.
This seems to be part of a more general issue that
digir.xsd is trying to be useful for both portals and
providers, but there are some undocumented(?)
differences in the requirements for both requests and
responses. On the request side, the optionality of the
resource attribute is an example. On the reply side, a
provider must never(?) wrap a response in a
ResponseWrapper, whereas a portal must always(?)
Here, we would rather see no difference between
portals and providers, especially in responses.
Otherwise, it is needlessly complex to build federating
applications that take data from both portals and
providers, no matter how discovered.