Re: [provision] Standard Schema draft 4.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

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?

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

>    *
>       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.

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

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

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).  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.

> [1] 
> http://www.oasis-open.org/apps/org/workgroup/provision/email/archives/200703/msg00010.html
>
> [2] 
> _http://www.oasis-open.org/apps/org/workgroup/provision/email/archives/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.
>