[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Re: [provision] Standard Schema draft 4.
Hi Gary, please see my comments marked with <MR>...</MR> below. - Martin >-----Original Message----- >From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM] >Sent: Dienstag, 24. April 2007 01:47 >To: Raepple, Martin >Cc: provision@lists.oasis-open.org >Subject: [LIKELY JUNK]Re: [provision] Standard Schema draft 4. > >Thank you, Martin. As always, I appreciate your thoughtful feedback. >My initial responses are inline below. > >Raepple, Martin wrote: > >> Hi, >> >> here are our comments and questions to the latest Standard Schema >> draft 4 [1]: >> >> * >> In the domain model diagram, Group should also have a >"performs" >> relationship to Role with the cardinality (0,N), similar to >> Person/Role >> >This is an interesting suggestion, which had not occurred to >me. I see >Groups most often as a secondary organizational structures--or >temporal >teaming structures--rather than as abstractions of Person. I >would like >to know whether others agree with your suggestion. I will >also consult >internally. > >> * >> The attribute Email-Address in Person is a multi-valued field, >> but there is no way to determine which address (in >case of many) >> is the preferred one by the user >> >I agree. Should we have one attribute named "Email-Primary" that is >single-valued, and another attribute "Email-Secondary" that is >multi-valued? <MR>Yes - I think that would help</MR> > >> * >> The Disable-Date and Enable-Date attributes should be >renamed to >> "Valid-From" and "Valid-To" >> >That works for me; I'm not too hung up on names. However, "Valid" >doesn't seem quite right--after all, an Account doesn't suddenly fail >validation. How about "Enabled-From" and "Enabled-To" (or >"Enabled-From-Date" and "Enabled-To-Date")? Why do you prefer "Valid" >to "Enabled"? <MR>Enable-From/To also works for me. In general, I think 'from/to' provide a clearer explanation of the semantics of these fields since they express a timeframe rather than unrelated dates.</MR> > >> * >> Person should have an address assigned to it >> >Yes, it should. And your comment about address in >Organization (below) >would then also apply to Person. <MR>Yes</MR> > >> * >> The current address structure in Organization only allows to >> assign one address. For real-world scenarios, this is not >> sufficient, since an organization (and person) usually has more >> then one address, based on different usages (delivery address, >> home address etc.) >> >Yes, an Organization (or a Person) might need more than one >address. In >general, do you see a primary address (analogous to Email-Primary >above)? Or are there multiple addresses associated with each >Organization (or Person), each having "Address-Type" as an attribute? > <MR>I'd prefer to have multiple addresses associated with a Person or Org. and have an attribute of Person/Org that points the standard/default address, e.g. by referencing its ID.</MR> >> * >> Since an Address can be a data structure of very >complex nature, >> it would be helpful to allow additional 'extension' attributes >> (please see also submission of SAP standard schema >proposal at [2]) >> >Should Address perhaps be an object class, so that each address is an >object and an Organization (or a Person) can have links to multiple >addresses? > <MR>If we want to provide multiple addresses associated with each Org or Person, than Address is good candidate for an object class.</MR> >Representing an address as a sub-object feels simpler than having an >attribute with a very complex and structured syntax. > >> * >> Why do AccountTemplate and AccountAttribute don't have a DN >> attribute like Person, Group, Role etc.? >> >AccountTemplate and AccountAttribute could have CN and DN attributes, >especially if these are commonly found in Directories. >As Jeff Bohren pointed out, these object-classes seem fairly >specific to >Provisioning Systems. >AccountTemplate and AccountAttribute are, in effect, meta-data (or >configuration data) for provisioning systems. > >> * >> According to sections 2.2 and 2.3, the meaning of Role is >> defined as a job function (that can span multiple roles in many >> systems/services), whereas AccountTemplate specifies a >> "concrete" role in a Service/system-specific way. In this >> context, an AccountAttribute could represent a concrete >> permission within a system-specific role, e.g. the >> "PurchasingAgent" AccountTemplate could have an >AccountAttribute >> "PurchaseOrderPermission". "PurchaseOrderPermission" itself >> might have multiple key/value attributes that define the actual >> actions that can be performed by this permission, e.g. >> "Action/Create", "Action/Delete", "Approval/>100k". Following >> this understanding, >> o >> an Account might have more than one AccountTemplate >> assigend to it (the diagram currently shows 0,N to 1 >> relationship) >> o >> AccountAttribute should provide an attribute that can be >> mapped to the key/value pairs as stated abov >> o >> the names "AccountTemplate" and "AccountAttribte" are not >> the best choice for these types of entities. Better names >> might be "System[Service]Role" and "Permission" (?) >> >Oddly enough, "AccountAttribute" was named "Permission" in an earlier >draft. However, reviewers and colleagues then pointed out that Roles >often imply (for the associated accounts) attribute values >that are not >limited to permissions. Some attributes are quotas, some are used >elsewhere to track access... The attributes (and values) are >essentially >arbitrary (from the point of view of the provisioning system). > >The suggestion that an Account should be related to multiple >AccountTemplates is interesting--that is new to me. Offhand, it seems >to me that this would conflict with the purpose described on page >10--that is, computing the set of accounts that should be >retained when >a Person's Roles change. Perhaps I misunderstand, but if a given >Account is based on multiple accountTemplates, each of which >governs an >arbitrary set of AccountAttribute values, then it seems to me >that these >accountTemplates could easily conflict (in terms of the >AccountAttribute >values that they imply). <MR>My understanding was that AccountTemplate is the system-specific representation of role which is defined on a business / functional job level. Wouldn't the limitation of allowing only one AccountTemplate per Account then mean that we need to have large number of AccountTemplates in the system(s), each representing the possible combination of role assignments at the business / application layer?</MR> Also, whenever the set of roles for a Person >changes, then the Provider would need not only to recompute the set of >accounts that would be retained, but the Provider would also need to >recalculate the set of AccountAttribute values that each >account should >now have (again, possibly conflicting). > >> * The Question and Answer entities don't seem to be on the same >> level of granularity as the other entities in the domain model. >> Therefore, we should move them to the Account entity as >> additional attribute >> >You are correct; the Question and Answer entities are not top-level in >the Domain Model. Each Answer is essentially a sub-object of the >Person; a Question is a shard configuration object to which any number >of Answers may be linked. > >As I understand its purpose, a (shared) Question must stand alone. (A >question that is person-specific is represented as >Question-Text within >an Answer.) > >An Answer could be represented as an attribute only (I >believe) if that >attribute had a complex and structured syntax. As I mentioned earlier >in the context of Addresses, I prefer to represent an Answer as a >sub-object. Representing each complex entity as an >object-class allows >each attribute to have a simple and relatively unstructured syntax. > >I believe that this may be the crucial difference between the SAP >Standard Schema recommendation and the current draft. If it is >acceptable to represent complex sub-entities as object-classes (rather >than as attributes that have attributes of their own), then >most of the >other differences in detail should be simpler to resolve. <MR>I think the representation of complex sub-entities as object classes is the better approach.</MR> > >> [1] >> >http://www.oasis-open.org/apps/org/workgroup/provision/email/ar >chives/200703/msg00010.html >> >> [2] >> >_http://www.oasis-open.org/apps/org/workgroup/provision/email/a >rchives/200702/msg00002.html_ >> >> - Martin >> >> >--------------------------------------------------------------- >--------- >> *From:* Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM] >> *Sent:* Dienstag, 27. März 2007 19:23 >> *To:* PSTC >> *Subject:* [provision] Standard Schema draft 4. >> >> Took a while, but I've attached a PDF. >> >> * This Introduction discusses SIMPLEST only as a schema (and >> not as a profile of SPML). The Protocol section has been >> removed accordingly. >> * The domain model is the same (although I've tweaked the >> names of the two entities in the lower-right-hand corner of >> the diagram: AccountTemplate and AccountAttribute). >> * The Schema section now reflects the object-classes and >> attributes from the spreadsheet that I sent to >(the list at >> the time of) the last Face-to-Face. >> * The Conformance section has been expanded. It now >> discusses extensions to the standard schema as well as >> arbitrary (i.e., undeclared extensions) object-classes and >> attributes. >> >> Obviously, this is just a draft, but it fairly represents the >> current proposal. This draft should serve as a basis for further >> discussion. >> >> * I have not incorporated anything from SAP's submission to >> the Standard Schema. I intended to do that, but it took >> longer than I expected merely to bring the draft >up to date. >> * It feels a little weird to propose a standard >schema without >> specifying a schema language. Perhaps we can show how >> (operations using) the standard schema would look in the >> DSML Profile or SAML Profile or XSD Profile. >> * The language in the Conformance section is still a bit >> tortuous. I can make the language clearer, given time, so >> what I need first and most is comment on the >*ideas* in this >> section. >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]