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
the <diagnostic>.

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(?)
do so.

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.

Bob Morris


  • Dave Vieglais

    Dave Vieglais - 2004-04-23
    • priority: 5 --> 2
    • assigned_to: nobody --> vieglais
    • status: open --> closed
  • Dave Vieglais

    Dave Vieglais - 2004-04-23

    Logged In: YES

    The issue with respect to portal behaviour is not
    particularly relevant, since the protocol only defines the
    interaction between the portal / client and the data

    An appropriate diagnostic should be returned in reponse to a
    malformed request, and this will be addressed in future


Log in to post a comment.