Re: [dss] XML Schema and conformance requirements

[Rich Salz <rsalz@datapower.com>]

> a) several of the application profiles will use the same set of elements.

I would like to understand why this is a problem.

> b) We will get a multitude of documents.

See below.

> c) There several different places in which we would want to add extensions

I don't believe this is true.

> Is there a way that we can collect together some generally useful elements
> that we do not expect all implimentations to support but are applicable to
> several applications profiles into one or very few documents.

Yes.  We could issue a "common extensions" document that defined a 
handful of dss:Parameter elements for various things.  The spec could 
say if you support this element, then it must be with the semantics 
defined here.  You could then make an easy interop matrix that listed 
the URI's of all the elements, and vendors and customers (and interop 
testing) could make a check-list of the URI's that are supported.

> I am not sure what you mean by "standards profile" as apposed to application
> profile and how this relates to use of extensions

I mean things like the way WS-I says "only use doc/literal not 
rpc/encoded for SOAP."  Or the way IETF PKIX says how to use X.509. 
It's where one document defines a "subset" (not strictly in the PKIX 
case, perhaps) of another.  That's a standards profile.

An application profile would be a URI embedded in each request that 
indicates to the DSS server what behavior(s) the client wants.  For 
example, "urn:tpu.int:timestamp:1.0" could be the URI that clients send 
if they want a postal-service timestamp.

Is that a better explanation?

	/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