> Please expand this agreement and line of reasoning to include any impacted
> output structures and request structures as well. Options are but a part of
> the puzzle.
No, Options is the *only* part of the puzzle, since that is the only
extensibility point. Any request should validate against the DSS core
schema definition. Now that I write that down, I think that's a
non-negotiable point. (I'm not sure, but I think so.)
Suppose a profile defines an optional element. Under your scheme, if
the client wants to use that element, it creates a message within the
profile's namespace (that contains the element). If it doesn't want to
use the element, it can still use the profile's namespace (since, of
course, the schema will be written to express the element's
optionality). Or, it can post to another DSS server, but that involves
creating a separate message under a different namespace. The net
effect, will be a *contribution* to closely tieing clients and servers.
(For a network protocol, as opposed to document, that follows this
model, consider the LDAP "control" structures.)
A client or server that wants to more strictly verify the Options can do
as Trevor suggested. It can publish a schema with the "any" replaced by
the specific elements it understands.
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
