RE: [provision] Remarks on the Draft Committee Specification 0.0

[Darran Rolls <Darran.Rolls@waveset.com>]

For the record, the conclusion of this discussion was a motion to make
the element mandatory at the 2/24/03 committee con call; passed by
majority, Jeff apposed.

Follow-on thought.  If I am using the
urn:oasis:names:tc:SPML:1.0:core#GenericString operationIDType then the
providerID probably should be mandatory anyway. 

--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
(512) 657 8360                    
--------------------------------------------------------


> -----Original Message-----
> From: Jeff Bohren [mailto:jbohren@opennetwork.com]
> Sent: Monday, February 24, 2003 7:55 AM
> To: provision@lists.oasis-open.org
> Subject: RE: [provision] Remarks on the Draft Commitee Specification
0.0
> 
> 
> It was my understanding that we decided to make the Provider ID
optional
> at the last F2F. One of the supported types for the operation ID (and
> schema ID) is a URN. URNs are by convention unique. If you use a URN
for
> an operation ID, then the Provider ID is redundant.
> 
> Darran, could you add an agenda item to discuss this today?
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
> 
> 
> -----Original Message-----
> From: Elron, Rami [mailto:rami_elron@bmc.com]
> Sent: Monday, February 24, 2003 8:43 AM
> To: provision@lists.oasis-open.org
> Subject: [provision] Remarks on the Draft Commitee Specification 0.0
> 
> The following remarks are with regard to the Draft Committee
> Specification
> 0.0 from 21 February 2003.
> 
> Extended Request issues
> 
> 			*	The SPML Extended Operations section
> (p.19)
> incorrectly states that the providerID sub element is optional. This
> error
> is also reflected in the first example appearing in the same page and
in
> page 25 (under 9.10 Element <ExtendedRequest>) - both missing the
> mandatory
> providerID.
> 			*	Still with the ProviderIdentifier, the
> "Schema" complexType definition in file
draft_pstc_schema_schema_02.xsd
> incorrectly associates a minOccurs=0 attribute to the
providerIdentifier
> element. The schema fragment example in the Draft Committee
> Specification
> (p.28) does not mirror this.
> 			*	The "ExtendedRequest" complexType
> definition
> in file draft_pstc_schema_schema_02.xsd does away with an independent
> ProviderIdentifier element, relying on the corresponding element of
the
> parent Schema. Though this is probably the typical scenario, a
situation
> where one provider schema includes support for another provider's
given
> extended request is not inconceivable and should be supported too.
> 
> Syntax & format issues
> 
> 			*	The Glossary (under 5. Introduction,
> p.7)
> should be expanded to include more terms, chief among which are
> (non-ordered): PSO, Binding, Provider and ProviderID, Request and
> Extended
> Request, Binding and Schema.
> 			*	On page 9, lines 151,153 - listings
> could be
> formatted differently than example codes for clarity.
> 			*	On pages 9,10 (under 6.2 'What is a
> provisioning system?') it might be easier to read the text if
component
> names were formatted in italics or boldface.
> 
> Other unclear issues
> 
> 			*	SPML Modify Operations resultCode values
> (p.17, line 424) should be explained. The meaning of "...#pending" for
> instance is not straightforward. When is it used? What does it
actually
> tell
> the receiver?
> 
> Comments
> 
> 			*	In light of examples such as in page 16,
> line 410, it might be a good idea to suggest (as a good practice) that
> 'numerical' string values be used instead of 'PseudoComboTyped'
strings
> (such as '50mb') - relieving the receiver from knowing how to parse
the
> string accordingly (the example mentioned is rather simple) and how to
> understand the meaning of whatever 'residue' is left after extracting
> the
> relevant figure. Standardizing appropriately typed schemas or
> alternatively
> providing ways to separate values from standard type captions might be
> helpful as well.
> 			*	With regard to 'SPML extensibility
> points
> (non-normative)' on p.29, good examples for Extended SPML Requests
are:
> Report, Route, [favorite administrative action here]
> 			*	The schema should include a definition
> specifying supported SPML functions so that a given RA/PSP/PST can
know
> this
> a priori and not by receiving error notifications. Moreover, this
> capability
> must be a mandatory requirement for compliance.
> 
> 
> 	Rami Elron
> 	Senior System Architect
> 	Security Business Unit
> 	BMC Software Ltd.
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>