Re: [dss] Core versus Extended Profile Handling

[Rich Salz <rsalz@datapower.com>]

> 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