OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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
> "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?

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]