[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Latest drafts of the schemas...
Gary,
Great feedback. See comments below:
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: Gary P Cole [mailto:Gary.P.Cole@Sun.COM]
Sent: Saturday, July 17, 2004 10:39 PM
To: Jeff Bohren; Gearard Woods
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Latest drafts of the schemas...
Thanks, Jeff and Gerry. This looks *great* expressed in wsdl and xsd.
(Of course, I wouldn't be me if I didn't have questions and comments.
At least you'll know that I read it. :-))
General.
I notice we don't have relationships. Do we have conceptual issues (or
just resource issues)?
[JSB] Both.
draft_pstc_spmlv4_core_5.xsd.
- ResultCode. Each resultCode is for an individual request.
BatchResponseType contains a sequence of these, one for each
batchableRequest in the BatchRequestType. Am I reading this correctly?
[JSB] Yes, that is correct. Each response in a batch response can have
it's own result code. This is the same as in SPML 1.0.
- IdentifierType. Why is IdentifierType an extension of
ExtensibleType? Is the idea that this *could* be a string-format "ID",
but could equally well be *anything*? If so, why does this need to be
so wide-open?
[JSB] Although the generic ID could be used, you could also use an XML
structure such as a SAML Subject Statement.
- PSOIdentifierType. (Same question as IdentifierType regarding
ExtensibleType. Also) I notice the absence of "name". Is the "id"
assumed to be globally unique and immutable (i.e., a guid)?
[JSB] The ID is not globally unique, but must be unique withen the scope
of the containing target. That is why the PSO ID has both the ID and the
Target.
- PSOType. I think I understand why a PSO would have an "id" and
"parameters", but why would a PSO have a *sequence* of {0-1
PSOIdentifierType, followed by 0-1 PSOParametersType}? Especially since
each of those id values is an instance of PSOIdentifierType, wihch
already contains a sequence of {0-1 id, followed by 0-1 target}? This
probably deserves annotation.
[JSB] The PSO Parameters are the PSO data. I am leaning towards getting
rid of this element completely as it does not really add anything.
- ModifyResponseType. Extends SpmlResponseType, but adds nothing. Is
this a placeholder to add something we may need? (Same for
DeleteResponseType, etc.)
[JSB]You are correct, this does not add anything. I will remove it in
the next draft unless some else feels strongly about it.
- SupportedCapabilityType. Does "appliesTo" specify a PSOType from the
schema? If so, this probably deserves annotation. Also, why specify
maxOccurs="1" on the *any*? Isn't this the default value?
[JSB] The applies to refers to a provisioning domain specific "object
type". For instances for LDAP provisioning the applies to would
reference and object class. For XML provisioning, the applies to would
reference and XSD type definition.
- ListTargetsRequestType. Extends SpmlRequestType, but adds only an
empty sequence. Is this a placeholder? Is there some other reason we
need to *extend* SpmlRequestType? Why do we need the sequence? This
probably deserves annotation.
[JSB] ListTargetsRequestType extends SpmlRequestType so as not redefine
all the SPML request/response model plumbing. It needs to be it's own
type so as to be deferentiated from other requests.
- CancelResultsType. For consistency, "nosuchRequest" should probably
be "noSuchRequest".
[JSB] Will fix in the next rev.
- StatusReturnsType. Do we need the space character at the end of
"status "?
[JSB] Will fix in the next rev.
- CancelRequestType. Extends SpmlRequestType but adds nothing. Is this
a placeholder? Is there some other reason we need to *extend*
SpmlRequestType?
[JSB] Same comment as for ListTargetsRequestType.
- StatusRequestType. Why does it mean for the request to specify
"statusReturns='status'"? Is this requesting a string-form status
message? What does it mean for the request to default to
"statusReturns='result'"? Does this request a(n enumerated)
ResultCode? This probably deserves annotation.
[JSB] This is the same as in SPML 1.0 and is documented there.
Requesting result type of "status" means return only the current status
of the request no matter what. Requesting result type of "result" means
return the current status as any results that may exist.
- StatusResponseType. Why are "complexType", "complextContent",
"extension" and "sequence" all prefixed with "xsd:" and in *only* this
type declaration? Also, why does the status response contain a
*sequence* of currentResponse? Does this sequence contain one element
for each target? Does this sequence contain one element for each
element in a batch request? This probably deserves annotation.
draft_pstc_spmlv2_core_5.wsdl.
draft_pstc_spmlv2_password_5.xsd.
- SetPasswordRequestType. Wouldn't the element named "pso" be better
named "identifier" or "psoIdentifier" or "psoId"? In the the core
AddResponseType, an element named "pso" was an actual object--an
instance of PSOType. Here the element is an instance of
PSOIdentifierType. (Same question/comment for ExpirePasswordRequest,
ResetPasswordRequest
and ValidatePasswordRequest.)
[JSB] It should be "identifier" to be consistent with modify and delete
operations. I will change this in the next rev.
- ValidatePasswordRequest. Typo in "documentation": "reset a password"
should be "validate a password" or, better yet, something as explicit as
"test a value against password policy".
[JSB] Will fix in the next rev.
draft_pstc-spmlv2_5.wsdl. Should be
"draft_pstc_spmlv2_password_5.wsdl", right?
[JSB] Will fix in the next rev.
draft_pstc_spmlv2_search_5.xsd.
- SearchQueryType. Extends ExtensibleType, but adds nothing. Is this a
placeholder for something we may want to add, or is this the only way to
compose an ExtensibleType? Also, if we're not going to add anything,
can't we just use "/>" rather than "</extension>"?
[JSB] There will probably be something else added. If not it will be
removed.
- IterateRequestType. I notice we don't have an "IterateResponseType".
Do we need one? Or is the response to an IterateRequestType an instance
of SearchResponseType? It looks like IterateRequestType is separate
request type (rather than a special case of SearchRequestType). This
probably deserves annotation.
[JSB] Yes, the intention is that response to the iterate request is
another search response, with a new iterator if needed.
draft_pstc_spmlv2_search_5.wsdl. Do we need an "IterateRequestMsg" or
"IteratePortType"? If not, how does one process an iterator? Does one
use the SearchRequestMsg and SearchPortType?
[JSB] Will fix in the next rev.
draft_pstc_spmlv2_state_5.xsd.
- SuspendRequestType. Wouldn't the element named "pso" be better named
"identifier" or "psoIdentifier" or "psoId"? In the the core
AddResponseType, an element named "pso" was an actual object--an
instance of PSOType. Here the element is an instance of
PSOIdentifierType. (Same question/comment for ResumeRequestType and
ActiveRequestType.)
[JSB] Same as before, it should be "identifier" to be consistent with
modify and delete operations. I will change this in the next rev.
- SuspendRequestType (again). Perhaps the documentation could be
enhanced to mention that the specified PSO is presumably active. If the
'suspend' operation is successful, the specified PSO will become
inactive.
- ResumeRequestType. Perhaps the documentation could be enhanced to
mention that the specified PSO is presumably suspended (i.e.,
inactive). If the 'resume' operation is successful, the specified PSO
will become active.
- ResumeResponseType. Typo in "documentation": change "Set Password" to
"Resume".
[JSB] Will fix in the next rev.
draft_pstc_spmlv2_5.wsdl. Should be "draft_pstc_spmlv2_state_5.wsdl",
right?
[JSB] Will fix in the next rev.
Gary
Jeff Bohren wrote:
> Attached is version 5 of the SPML 2.0 schemas. This draft includes
> Gerry's suggestions for the modify and search request. It also
> includes an iterator for search requests.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]