OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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
0.0 from 21 February 2003.

Extended Request issues

			*	The SPML Extended Operations section
incorrectly states that the providerID sub element is optional. This
is also reflected in the first example appearing in the same page and in
page 25 (under 9.10 Element <ExtendedRequest>) - both missing the
			*	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
(p.28) does not mirror this.
			*	The "ExtendedRequest" complexType
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,
should be expanded to include more terms, chief among which are
(non-ordered): PSO, Binding, Provider and ProviderID, Request and
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
the receiver?


			*	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
relevant figure. Standardizing appropriately typed schemas or
providing ways to separate values from standard type captions might be
helpful as well. 
			*	With regard to 'SPML extensibility
(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
a priori and not by receiving error notifications. Moreover, this
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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC