Venkata Krishnan wrote:
Hi,The Assembly and Policy Fwk specs mention that domain-wide definitions such as policy intents, policysets, binding type defns, impl type defns all defined in a 'global, domain-wide file' named. definitions.xml A single domain wide file with all definitions may not play well with extensibility. Here are some cases which seems to necessitate the existence of several definitions.xml file the contents of which could all be aggregated into a single bunch of 'domain wide definitions'. 1) For every binding / impl type in the domain there is a definition in the definitions.xml for the intents supported by the binding/impl. So whenever a new binding/impl is addeded the definitions.xml needs to be edited 2) Application Policy Administrators typically define policysets for various intents including the set of standard intents as specified by the specs such as confidentiality, integrity and authentication for the security domain. The administrator defines these policysets typically in the definitions.xmlfile. Should the administrator also be encumbered with having to add the definitions for the standard intents as well or should the administrator be actually editing the file we are going to package and making application additions there? So it seems to me that there are two options... i) Have a single definitions.xml file in our domain module and expect that it be edited for every new binding/impl type and then by application adminsitrators for application specific things ii) Allow each binding/impl type to have its own definitions.xml file and also allow contributions to have a definitions.xml file and then aggregate all of these definitions. I am convinced about about option (ii) and am looking at making the changes for this unless people have serious objections. Can folks in the specs group provide their perspective to this ? Thanks - Venkat
My 2c. Let's develop the bigbank-secure scenario. We're gonna bump into this right away with the scenario. Let's see what makes sense then in the light of the concrete scenario.
-- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
