[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,
We've had all these arguments before and we could go back and forth for
days on this. The bottom line is that I feel the SPML 1.0 was railroaded
through for marketing purposes to make Catalyst. The official argument at
the time against a Web Services approach was that the committee would lose
both credibility and an investment in work already done. You argued
vigorously, almost violently, against what we were trying to propose
because, you said, directories are proven and our approach wasn't. Now
here we are again, there is too much investment in the current path and
directories are proven.
I'll re-iterate my previous high-level arguments for the record:
- The SPML should interoperate seamlessly with Web Services
- The SPML should itself take advantage of, and be implemented using,
accepted Web Services standards
- The SPML should offer a Provisioniong model, not a directory model. This
point is very relevant at this juncture because had the SPML 1.0 offered a
provisioning foundation we would now be discussing what a richer
provisioning model would look like rather than how we might cram XML Schema
and XML data into a directory protocol.
These things seem self-evident, just as the creation and refinement of
another directory protocol seems redundant. Your roundup of
attribute/value protocols and products makes it clear that there are plenty
already but fails to mention that SPML is, in fact, crippled as compared to
the directory protocol is is based on, DSMLv2. Your recent e-mail on the
search limitations indicate that you fully understand this. The roundup
also fails to acknowledge that directory vendors are putting a lot of
thought into how to get around the very problems we are discussing,
initiatives such as XED illustrate this. But here is a protocol hot off
the press that has all of the traditional directory limitations and more
built right in from the start. You'll forgive me if I don't consider the
SPML1.0 to be an appropriate foundation for the future of provisioning
interfaces. It's a good reflection of the past though, I'll give you that.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/02/2003 05:53 |
| | 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,
I agree that we should be willing to consider all options for SPML 2.0. I
would be willing to consider just about anything including a total rewrite
if that is what is required to meet the requirements for 2.0. But I am not
going to support a total rewrite if the requirements can be met with an
approach that is backwards comatible with the current spec. Of course we
have not finalized the requirements so that decision can not be made yet.
At highest level the SPML 1.0 spec is based around the concept that the
provisioning data is represented as a collection of attribute/values rather
than arbitrary XML. This is the approach taken by SAML as well as SPML. It
is also the approach taken by many of the currently provisioning products
in the market place. Many workflow, EAI, and BPA products use this approach
as well. And of course it is also how all directory, meta-directory, and
virtual-directory products work. Given that, I don't think it is reasonable
to characterize that approach as "crippled" or "worthless".
My suggested compromise for SPML 2.0 is that the provisioning data be
represented as a collection of attribute/values plus arbitrary XML where
appropriate. Under this approach provisioning target developers are free to
use as much as needed from either model. People who already have
provisioning targets (as we do) don't have to be impacted. This approach is
not perfect, as compromises seldom are.
I have a hard time believing that not being able to represent provision
schema solely through XSD means that the spec has to be rewritten. It seems
that there should be a compromise somewhere in between. If not the one I am
suggesting, then perhaps another one.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tue 12/2/2003 6:21 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML 2.0
submission from IBM
Jeff,
You know the history of this debate as well as I do, including
the rush to
demo at Catalyst in the face of the strenuous objections of
both ourselves
and Microsoft. Now you are using exactly the same arguments
as you used
then. We have committed to try to work with the committee as
part of the
SPML 2.0 effort but if we are not to debate the merits of
different
approaches now then there is no debate. I'd like to point out
too that a
radical departure from an earlier approach is not
unprecedented - an
example close to your heart would be the fact that DSMLv2 is
obviously a
far cry from DSMLv1.
I'm not saying that WS-Provisioning does not require that a
client retrieve
the schema. What I'm saying is that it doesn't get in the way
by imposing
a proprietary schema language. If you are using XML Schema
then you get
XML Schema, not XML Schema shoehorned into another schema
language.
In terms of the respect that SPML 1.0 deserves, in my book
that's something
that results from being tested and implemented and found to be
thorough,
robust and appropriate. As you know we will not be
implementing it. In
terms of the utility that it represents, in any large scale
application,
which the interop demo was not, the limitations of the spec
are crippling.
It's encouraging to see that you recognize that there is
merely "some"
level of interoparability because to claim interoperability
for a demo in a
highly controlled environment with 10 simple attributes would
be
overstating the case.
If the committee is to try to build a provisioning standard
rather than
another directory protocol, then it should not be built on the
SPML 1.0
schema language, simple as that. If you are prepared to
commit
wholeheartedly to the use of XML Schema then let's dispense
with the SPML
schema language altogether. Sure, make it backward compatible
but with
SPML 2.0 as a superset, not as a dependant specification.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/02/2003 12:30 |
| | PM |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <provision@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [provision] Discussion and analysis of
SPML 2.0 submission from IBM |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
I will try to flesh out the examples more in the next
iteration of the
OpenNetwork proposal. I should hopefully have that done soon.
I agree with you about the SPML Identifier. In retrospect a
pure urn
based approach would have served better. I would like to make
that
change in SPML 2.0 so as to allow for either the current
identifier
approach or a URN approach.
You seem to be implying that in WS-Provisioning an XSD based
tool could
somehow use the provisioning target schema definition to do
something
useful. The WS-Provisioning approach requires that the client
queries
the service to get the provisioning schema, and parses the
result. For
instance if you wanted to automatically generate client code
then you
would have to create a WS-Provisioning specific tool to do it.
This is
true with both proposals.
Now whether SPML 1.0 had compelling features that make it
worth being
backwards compatible with is certainly a matter of opinion.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]