[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Core versus Extended Profile Handling
Q1: Extensibility The problem I see with A (extend base class) is that it does not allow for feature-mixing: how can I write a profile C that uses features A and B? It also makes fallback and error diagnosis hard; a DSS server that is sent a profile it doesn't understand will just see some random uri/element combination, and can't respond with a useful fault "I don't understand foo:bar option" I like B because it is what XML DSIG uses. Since we are defining a "remote access" or something that generates DSIG (yes, and perhaps more), it seems like a no-brainer to follow their style. C has the same problems as A, but is done in a implementation style. Q2: Should core define some things that might be useful but are optional (Did I summarize that right?) I'm neutral. DSIG defined things that folks might find useful, but they haven't gotten widespread use. If there's something completely obvious, then I would feel most comfortable putting it in a non-normative appendix. Q3: How define conformance The trend seems to be to follow the IETF MUST/MAY/SHOULD model (see http://www.ietf.org/rfc/rfc2119.txt). I can't see any reason not to follow that model. As for branding, testing, etc., I think we should either have a separate conformance TC (as with XSLT, for example), or hope we're useful enough that WS-I does it. /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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]