RE: [dss] XML Schema and conformance requirements

["Nick Pope" <pope@secstan.com>]

Rich, Juan Carlos

My concern of putting these "extensions" elements in several separate
documents is that:

a) several of the application profiles will use the same set of elements.
b) We will get a multitude of documents.
c) There several different places in which we would want to add extensions

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.

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

Nick
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: 17 September 2003 17:02
> To: Juan Carlos Cruellas
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] XML Schema and conformance requirements
>
>
> > I still think that it could be useful to develop a XML schema complete
> > enough as to allow
> > those requesters that do not find a profile matching their
> needs to manage
> > their problem.
>
> Sure, and following the structure of dsig:Transforms allows that.  Do
> not define a set of optional elements.  Define a place holder and
> require all elements to fit inside a standard container.  This models
> what DSIG does, what cert extensions (oid/criticality/value) look like,
> and so on.
>
> In fact, the more I think about it, the more I like the idea of a
> "criticality" flag.
>
> > Nevertheless, we could define in our standard a set of CONFORMANCE
> > REQUIREMENTS for the
> > "core protocol" that will establish that those elements that
> > are seen as unnecesary when an application profile
> > can be defined, WILL NOT APPEAR.
>
> I believe this is too limiting.  An app protocol -- a URI that specifies
> what the server to do -- may still have optional parameters.  I view a a
> DSS app profile as saying "this is what I am going to do, in the absence
> of other information."  The "this is what I am going to do" part may
> include "it is an error to provide any other parameters" or it may say
> "I support the http://www.example.com/2003/timestamp element, the ...
> element," etc.
>
> When I was using the word "profile" I didn't mean an application profile
> as specifeid by URI, but rather a "standards profile" like WS-I does.
>
> I do not see why you put something in the core, and then make it
> optional.  This makes it hard for customers to specify what they want:
> "DSS conformance, with optional 6.2.1 section implemented"  Why not put
> each item in a separate document?  It is very easy, then, for customers
> to list the documents they require conformance to.  It also shows how
> customers can provide their own requirements -- while still fitting in
> the interopable DSS scheme -- just write your own doc.
>
> Is the difference between "app profile URI" and "wsi-like spec profile"
> more clear now?
> 	/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
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php.