|
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
-
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
-
The Disable-Date and Enable-Date
attributes should be renamed to "Valid-From" and "Valid-To"
-
Person should have an address assigned
to it
-
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.)
-
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])
-
Why do AccountTemplate and
AccountAttribute don't have a DN attribute like Person, Group, Role
etc.?
-
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,
-
an Account might have more than one
AccountTemplate assigend to it (the diagramm currently shows 0,N to 1
relationship)
-
AccountAttribute should provide an
attribute that can be mapped to the key/value pairs as stated abov
-
the names "AccountTemplate" and
"AccountAttribte" are not the best choice for these types of entities.
Better names might be "System[Service]Role" and "Permission"
(?)
- 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
[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
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.
|