[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Remarks on the Draft Committee Specification 0.0
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC