[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC