RE: [provision] Liberty Identity Personal Profile example...

[Gearard Woods <gewoods@us.ibm.com>]

Jeff,
Can you point out where in the Liberty specification it explicitly states
this?
Thanks,
Gerry



|---------+---------------------------->
|         |           "Jeff Bohren"    |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           07/31/2003 06:14 |
|         |           PM               |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       "Jeff Larson" <Jeff.Larson@waveset.com>, Gearard Woods/Irvine/IBM@IBMUS                                      |
  |       cc:       <provision@lists.oasis-open.org>                                                                             |
  |       Subject:  RE: [provision] Liberty Identity Personal Profile example...                                                 |
  >------------------------------------------------------------------------------------------------------------------------------|




Jeff,

I think you are misinterperting the whole purpose of the batch request. The
only reason that you would use a batch request would be to group logically
related operations. While this is implementation dependent, I would think
that a batch request going through workflow would be approved or denied as
a whole. If operations or not logically related then they should be
independent requests.

I am not a Liberty expert, but looking at the spec for the Personal
Profile, it is very clearly LDAP oriented (or X.500 oriented). It would
seem that a hierachical model would fit it quite well. But there are many
solutions to this problem in addition to the ones I posted.

I do see a lot of value in adding explicit support for complex data types
in the post 1.0 effort. Rami has made some interesting suggestions and I
have some ideas on my own. The only requirement that I would make is that
whatever approach we adopt can support reliable mamagement of the complex
data. Obviously the Liberty group did not feel that was important since
thier spec explicitly says that thier protocol does not support that.

Jeff Bohren
OpenNetwork Technologies



             -----Original Message-----
             From: Jeff Larson [mailto:Jeff.Larson@waveset.com]
             Sent: Thu 7/31/2003 4:29 PM
             To: Gearard Woods; Jeff Bohren
             Cc: provision@lists.oasis-open.org
             Subject: RE: [provision] Liberty Identity Personal Profile
example...




             Sorry I haven't had time to remain current on this topic.  I
don't
             have anything to say on the schema representation debate right
now,
             but I did want to comment on the recent examples attempting to
             represent complex data types.

             I dislike the notion of describing what will usually be
considered an
             atomic operation on a single object as a batch of SPML
requests.  For
             starters, any PSP more complex than a directory will likely
incur a
             substantial amount of overhead processing an add or modify
request so
             you don't want to treat these like discrete transactions even
though
             the end result may be the same.  It is not uncommon to require
             workflow approvals on any modification, this approach could
result in
             multiple approvals.

             So now, the PSP has to analyze every batch to determine which
requests
             can be semantically merged into a single transaction.  Batch
execution
             mode better not be sequential.  A similarly complex inverse
             transformation then needs to be performed to make what
internally was
             a single transaction appear as multiple responses in the batch
             response.

             Regarding the Hierarchical method:

             It isn't obvious to me how the DN-like <spml:id>'s work to
identify
             subcomponents, but I'll assume that's due to my relative lack
of LDAP
             experience.  I don't especially like the data duplication
though.

             Regarding the Referential method:

             This looked more obvious to me than the Hierarchical method,
but I
             would NOT want to be required to retain these GUIDs for later
             identification of the interior objects.  Again I would expect
many
             PSPs that aren't implemented on directories are going to have
problems
             maintaining GUIDs for things that are not "first class"
objects in
             their database model.

             But if the GUIDs aren't retained, how do I issue a
modifyRequest to
             change just the AltCN attribute?


             While I'm not necessarily suggesting this as a solution,
Waveset
             solves very similar problems by flattening a complex
hierarchical data
             model into a list of attributes whose names are "paths" into
the
             hierarchy.  Our path syntax is non-standard, but for the sake
of
             example,
             the little XML document would be exposed using the following
             attribute names:

                  InformalName
                  CommonName.CN
                  CommonName.AltCN
                  LegalIdentity.LegalName
                  LegalIdentity.VAT

             We're using this approach right now to squeeze extremely
complex
             hierarchical objects through SPML.  We use the same technique
to edit
             these objects in a web GUI.  HTML forms post a flat list of
name/value
             pairs, you have the same problem.

             Yes, it is cumbersome.  I would really prefer complex data
types in
             SPML, but this does work and I would choose it over the
previous two
             methods because it maintains the atomicity of the request.

             I think we should continue exploring the consequences of
introducing
             complex data types into SPML.  I just wanted to point out what
I think
             is a simpler way to make complex data appear flat.

             Regards,
             Jeff