OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM






Jeff,
I think you might not be remembering our original proposal correctly.  We
have always advocated the use of a target object to hold schema.  I plucked
the following segment from an e-mail in the list archives dated February
28th of this year:

...
      <complexType name="ProvisioningTargetSchema">
            <sequence>
                  <any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
            </sequence>
      </complexType>

      <element name="ProvisioningTarget">
            <complexType name="ProvisioningTargetType">
                  <sequence>
                        <element name="identifier"
type="tns:ProvisioningIdentifier" minOccurs="1" maxOccurs="1"/>
                        <element name="schema"
type="tns:ProvisioningTargetSchema" minOccurs="0" maxOccurs="1"/>
                  </sequence>
            </complexType>
      </element>
...

You'll find this almost verbatim in our submission.  It was never a
suggested that the target schema had to be embedded in WSDL.

As far as the portions of the SPML that should be kept, as I said earlier,
and as you well know, our problems go to the heart of the spec.  The
SPML-specific schema language is unsatisfactory for a number of reasons
that we've discussed at length already.  The schema then dictates the data
model - that XML-unfriendly attribute-value data model that we have also
discussed at length already.  The schema and data model then impact the
operational interface.

I don't want to suggest that we at an impasse but I do think that any
proposals based on the SPML schema language will not come close to
satisfying our requirements.  The SPML must allow the use of XML Schema as
the target schema language, at a minimum.  Not as a tacked on band-aid but
as a first-class schema language.  It must also provide for the transport
of XML data as XML data - no wierd transformations or encodings.  The
reasons for these requirements are obvious and particularly imperative in a
Web Services context.  Fixing these demands a major overhaul of SPML 1.0.
Gerry



|---------+---------------------------->
|         |           "Jeff Bohren"    |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           12/01/2003 05:47 |
|         |           PM               |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       Gearard Woods/Irvine/IBM@IBMUS                                                                               |
  |       cc:       <provision@lists.oasis-open.org>                                                                             |
  |       Subject:  RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM                                      |
  >------------------------------------------------------------------------------------------------------------------------------|




Gerry,

It would be helpful to make a proposal of what parts of the current SPML
1.0 specification should be kept as is and what should be replaced or
modified. That way we can have a useful discussion on the mail list leading
up to the next face to face.

For instance you originally insisted that the only acceptable way to
represent the meta-data of the provisioning target (i.e. the provisioning
schema) was to represent it in XML Schema in WSDL so that client could be
auto-generated. Now in your WS-Provisioning submission that approach is not
taken. Instead the client gets the schema using a "FetchTargetRequest", and
processes the "FetchTargetResponse" in order to read the schema. Since you
have already abandoned a pure WSDL approach for representing schema, why
could that not be merged into the current SPML schema mechanism?

Jeff Bohren
OpenNetwork Technologies



             -----Original Message-----
             From: Gearard Woods [mailto:gewoods@us.ibm.com]
             Sent: Mon 12/1/2003 4:42 PM
             To: Jeff Bohren
             Cc: provision@lists.oasis-open.org
             Subject: RE: [provision] Discussion and analysis of SPML 2.0
submission from IBM







             I think it's fair to say that the submission is intended to
act as a
             statement of direction, indicating the form that we would like
to see the
             SPML take.  We've been quite clear about the fundamental
problems that we
             have with the current approach and on many occasions have
pointed out that
             these issues need to be addressed at the foundations of the
SPML.
             Reconciling the SPML1.0's schema and data models with the
direction
             detailed in our submission is not trivial.  It is certainly
not a
             cut-and-paste exercise.  The question to me is what portions
of the SPML
             can be retained to meet our needs.  At present those are few.



             |---------+---------------------------->
             |         |           "Jeff Bohren"    |
             |         |           <jbohren@opennetw|
             |         |           ork.com>         |
             |         |                            |
             |         |           11/25/2003 06:56 |
             |         |           AM               |
             |---------+---------------------------->

>------------------------------------------------------------------------------------------------------------------------------|

               |
|
               |       To:       <provision@lists.oasis-open.org>
|
               |       cc:
|
               |       Subject:  RE: [provision] Discussion and analysis of
SPML 2.0 submission from IBM                                      |

>------------------------------------------------------------------------------------------------------------------------------|





             The IBM Proposal looks to be a very good specification on it's
own merits,
             but has no compatiblity with the current SPML 1.0
specification. What
             exactly is IBM proposing? Is IBM proposing the the current
SPML
             specification be wholesale replaced with the IBM proposed
specification? Or
             is IBM proposing this as input into the SPML 2.0
specification?

             If IBM is proposing this as input rather than a wholesale
replacement, what
             parts does IBM feel are appropriate to incorporate into the
SPML 2.0?


             Jeff Bohren
             Product Architect
             OpenNetwork Technologies, Inc

             Try the industry's only 100% .NET-enabled identity management
software.
             Download your free copy of Universal IdP Standard Edition
today. Go to
             www.opennetwork.com/eval.

                   -----Original Message-----
                   From: Darran Rolls [mailto:Darran.Rolls@waveset.com]
                   Sent: Tuesday, November 25, 2003 9:46 AM
                   To: provision@lists.oasis-open.org
                   Subject: [provision] Discussion and analysis of SPML 2.0
submission
                   from IBM

                   As you are no doubt aware, IBM has submitted a
specification document
                   to the PSTC for consideration as content and
requirements for SPML
                   Version 2.0.  This submission can be found at [1].  Do
you have
                   questions regarding the intent, status or content of
this submission?

                   [1]
http://www.oasis-open.org/archives/provision/200310/msg00001.html







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]