I'd
like to invoke newbie privilege to go where wiser men tread not. That is,
between you two. :-)
I'm a
little uncomfortable with the vehemence of this discussion, but I
guess I'll get used to it. You two must know each other rather
well. Both of you know more about standards and specifications than I
do, but I'd like to try to net this out.
Analysis:
Jeff
proposed an extensible root that allowed for compatibility with the
1.0 DSML model.
This
came at the price of having what looks like a separate binding for XML
schema.
Jeff
likes the 1.0 DSML schema because it explicitly supports the data model used
by directories.
However,
this LDAPish model doesn't lend itself to complex data
objects.
Sandy
Walsh points out that much of the 1.0 spec dealt with schema
definition.
Sandy
suggests that leaving this to XML schema is more standard (and cleans
up the spec).
Opinion:
I like
the *idea* of compatibility with the 1.0 spec, but it's not
worth a separate binding.
If I had to choose one, I'd choose
pure XML schema for 2.0.
Gary
ps.
Did I get
it approximately right? Did I miss any important
points?
That is not exactly what I meant. I could see the SPML 2.0 spec being
divided into a core specification that defines the basic protocol from a data
agnostic point of view. Then two or more "profiles" could be defined that
define the data model and schema notation to use. If we took that approach
then the core specification would not include any notion of the SPML 1.0
schema notation, but an "Attribute/Value Profile" would. The "XSD Profile" and
would not have any notion of the SPML 1.0 schema notation, but would define
normative usage of the XSD schema notation.
Using this approach, the SPML 1.0 schema notation would be defined in the
SPML 2.0 specification, but only in the "Attribute/Value Profile" and not in
the core protocol. The implementors who wished to use it, could do so and know
they are following and accepted standard, and those not supporting that
profile need not worry about it.
Jeff Bohren
OpenNetwork Technologies
-----Original Message----- From: Gearard Woods
[mailto:gewoods@us.ibm.com] Sent: Tue 3/2/2004 5:57 PM
To: Jeff Bohren Cc: provision@lists.oasis-open.org
Subject: RE: [provision] One or many data
models?
Jeff, This is exactly what I've been arguing, that any proposal for a
2.0 should not build in a reliance on the 1.0 schema. I've agreed with you
already that in terms of communicating the schema there is no functional
difference. The difference is in building in the
dependency. Gerry
"Jeff Bohren"
<jbohren@opennetwork.com>
Again, there is no functional difference. The ONT Proposal
could easily accomodate that model, although I did not call it out in the
proposal. The schema response could be defined without any explicit
dependencies on the spml:schema or the xsd:schema elements. Any schema
notation could be used.
If the proposal was clarified to make the schema notation as
well as the schema detemined at runtime, would you still have an objection
on this issue?
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: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent:
Tuesday, March 02, 2004 5:29 PM To: Jeff
Bohren Cc:
provision@lists.oasis-open.org Subject: RE: [provision]
One or many data models?
Jeff, You're missing my point, or perhaps you're just
ignoring my point. It might help to review the approach used in the
schema-related aspects of the WS-Provisioning document to see what I
mean. It is probably not worth repeating again, but against my better
judgement I will say this: WS-Provisioning does not require that target
schema be defined using XML Schema. The actual schema language used by
the target is not codified into the specification, as it obviously is in
the ONT proposal. There is a simple, but nonetheless profound, and
apparently confusing, difference here. Gerry
"Jeff Bohren"
<jbohren@opennetwork.com>
In one
method an spml:schema element is returned and in another an xsd:schema
element is returned. The fact that the spml:schema element is defined in
the spml specification and the xsd:schema is defined in the XML Schema
specification does not make any functional difference. They are both
standard schema notations.
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: Gearard
Woods [mailto:gewoods@us.ibm.com] Sent: Tuesday,
March 02, 2004 3:52 PM To: Jeff
Bohren Cc:
provision@lists.oasis-open.org Subject: RE:
[provision] One or many data models?
I think I'm still being unclear. What I'm
referring to is the inclusion and reference to the specific
schema language in the spec. Specifically, the ONT proposal
includes the notion of an "spml" attributeDefinition and
objectClassDefinition. These include specific references to the
SPML 1.0 dsml-based model. This is not a runtime construct, it's
embedded in the schema for the proposal. The WS-Provisioning
approach is to leave the schema language definition out of the
specification and have it be described at runtime. Simply
because in the ONT proposal the schema is delivered using a
runtime request does not mean that it is the same thing at all.
Surely you see the distinction here.
I'm obviously
repeating myself but the point is that by embedding the SPML1.0
constructs, through inclusion of the schema and use of the
types, you are now "bound" to that
legacy. Gerry
"Jeff Bohren"
<jbohren@opennetwork.com>
Under the ONT Proposal the SPML
client may issue a schema request to the spml service. The
response will indicate whether the provisioning schema is
defined using SPML schema notation, or XSD schema notation, and
will include either the provisioning schema itself, or a
reference to an external XSD document. In both cases both the
schema notation and the schema are determined at call time (i.e.
late binding).
The only difference would be in who
defined the schema notation. In one case the schema notation
would be defined by the SPML 2.0 specification itself, and in
the other the schema notation is defined by the XML Schema
speciciation.
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: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tuesday, March 02, 2004 1:05
PM To: Jeff Bohren Cc:
provision@lists.oasis-open.org Subject: RE: [provision] One or many
data models?
I disagree that the two
proposals look the same from the point of view
of the "late-binding" idea that I brought up.
Perhaps I'm not making it clear. What I'm saying
is that, for example, the DSMLv2 schema is
"bound" into SPML 1.0 by virtue of its being
imported into the schema. I'm suggesting that
the SPML 1.0 not be "bound" into SPML 2.0 but
rather that the client can determine the schema
language at runtime based on providing them with
adequate namespace information. The key is the
difference between this runtime behaviour and
the inclusion of the specifics of the schema
language in the specification.
That the
two approaches can be made to be functionally
the same is of course my argument. There is,
however, a big difference between the writing of
a specific schema language into the spec, and
the ability to offer support for it without such
a tight coupling. As for two bindings, we could
certainly discuss it, but the SPML 1.0 is
already defined and the schema is already
available, so it can be used as is in my
opinion.
None of the three reasons you
propose negate this
argument. Gerry
"Jeff
Bohren" <jbohren@opennetwork.com>
There
are good reasons why the SPML 1.0 schema
language should be carried forward into the 2.0
specification:
1) This approach was
approved by 15% of the OASIS members at the time
(over 40 members) 2) It is being using by
existing commercial software products 3) It
explicitly supports the data model used by all
LDAP directories, virtual directories, and
meta-directories
Perhaps the best
approach would be to define the SPML 2.0 spec in
terms of a core protocol and two "profiles" or
"bindings". One "profile" could define
attribute/value data model and associated schema
language and one could define the xsd data
model. Implementors could decide whether to
support one or both of the profiles and we could
let the market decide which is
better.
One point of clarification, the
ONT SPML 2.0 Proposal also supports the notion
of late binding as described below. Whether a
specific SPML service uses the SPML 1.0 schema
langauge, xsd, or a mixture of the two is
returned in the schema response. In that sense
there is little functional difference between
the two proposals.
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: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tuesday, March 02, 2004 1:14
AM To: Darran Rolls Cc:
provision@lists.oasis-open.org Subject: Re: [provision] One or many
data models?
I should clarify what my
argument is here because it really has less to
do with supporting two data models than it has
to do with building the 1.0 schema language and
data model into the 2.0 spec. I am all in favour
of allowing the transport of SPML 1.0 schema and
data within 2.0 messages. What I don't think is
a good idea is making it part of the spec. Once
it becomes part of the spec then any
implementation will have to support it and it
will be perpetuated into all of the future work
on the SPML. I would prefer that the means to
use the schema language and SPML 1.0 data within
the 2.0 framework should be done as was
suggested in WS-Provisioning and as I
demonstrated at the F2F, i.e. by allowing
clients to discover the schema language in use
by namespace, a "late-binding" approach if you
will. This breaks the tight coupling between the
schema language and the spec, and allows 2.0 to
progress without having to carry the
restrictions of 1.0 with it forever
more. Gerry
"Darran
Rolls"
<Darran.Rolls@waveset.com>
As discussed, the
committee has to decide on the data model for
the 2.0 specification. On the one hand, as
prototyped by Jeff Bohren at the last F2F
meeting, we can devise a solution that keeps the
1.0 DSML data model by adding an extensible
schema "root" that allowed for its coexistence
with a new "XML Schema" data model. The "cost"
of this model is increased complexity. On the
other hand we can take a single data model
solution as proposed by Gerry Woods at the F2F
and base 2.0 on a pure XML Schema data model at
the "expense" of 1.0/ 2.0 compatibility and
backwards support for 1.0 in a 2.0 compliant
service.
Please consider this
issue and ask questions/state preferences now. I
propose we hold a ballot on this issue around
the next committee con-call 3/16/04.
Thanks Darran
<<pic05633.gif>>
|