RE: [dss] Core versus Extended Profile Handling

["Edward Shallow" <ed.shallow@rogers.com>]

Guys,

    I don't mind following this track if it takes us to completion, but the
profile engagement rules are clearly evolving from eMail to eMail. Don't
shoot the messenger, I'm simply looking for (helping to flush out ?) a way
to write a profile. If writing a profile is obvious to everyone on the list
but yours truly, then excuuuuuse meeee.

    I will try out some options along these lines, run them thru XMLSPY, and
pass them by you.

Ed

  

-----Original Message-----
From: Rich Salz [mailto:rsalz@datapower.com] 
Sent: November 7, 2003 3:09 PM
To: Edward Shallow
Cc: dss@lists.oasis-open.org
Subject: Re: [dss] Core versus Extended Profile Handling

> 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