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>>
|