[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [provision] Groups - SPML Errata Draft 5 (pstc-spml2-errata-draft-05.doc) uploaded
This is the new errata item that I would like to address on today's call. My preference is to create a new errata item rather than trying to put this into one of the existing errata. Jeff B. -----Original Message----- From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM] Sent: Tuesday, July 24, 2007 3:23 PM To: Bohren, Jeff Cc: provision@lists.oasis-open.org; Clyde Adley Subject: Re: [provision] Groups - SPML Errata Draft 5 (pstc-spml2-errata-draft-05.doc) uploaded I may have found one more item related to <spml:modification> for the Errata. The issue is closely related to E1, which addresses the conflict between the SPML 2.0 Specification and the SPML 2.0 DSML Profile with regard to the <spml:component> sub-element of <spml:modification>. A similar conflict exists between the Specification and the DSML Profile with regard to the <data> sub-element of the <spml:modification> element. The SPML 2.0 Specification, in section 3.6.1.4.1 "modifyRequest", states that: Modification data. A requestor MUST specify as the content of the <data> sub-element of a <modification> any content or value that is to be added to, replaced within, or deleted from the element or attribute that the <component> (sub-element of the <modification>) specifies. This has led several users of SPML to code a modifyRequest with the <dsml:modification> nested within an <spml:data> sub-element of the <spml:modification> element, as shown below: <spml:modification> <spml:data> <dsml:modification> </dsml:modification> </spml:data> </spml:modification> The SPML 2.0 DSML Profile, however, disagrees. Section 3.3.3 Modify Request shows the <dsml:modification> element nested directly within the <spml:modification>, as follows: <spml:modification> <dsml:modification> </dsml:modification> </spml:modification> Section 4.2.2 of the DSML Profile states that the <spml:modification> element MUST contain zero or many <dsml:modification> elements. Have we already discussed this? Perhaps Errata item E1 could be amended so that it also addresses the <data> sub-element. Alternatively, we could insert a new E2 that does the same thing for the <data> sub-element that we did for the <component> sub-element. Either way, we're just loosening the Specification so as to remove the conflict with the DSML Profile. If we change the title of E1 from "Relaxed requirements for the use of <component>" to "Relaxed requirements for the use of <component> within <modification>", this might make it easier for the reader to understand that <modification> is affected. We could add an E2 "Relaxed requirements for the use of <data> within <modification>" (or we could combine both into a longer E1 "Relaxed requirements for the use of <component> and <data> within <modification>"). Gary Cole Jeff_Bohren@bmc.com wrote: > The document named SPML Errata Draft 5 (pstc-spml2-errata-draft-05.doc) has > been submitted by Mr. Jeff Bohren to the OASIS Provisioning Services TC > document repository. > > Document Description: > SPML Errata Draft 5. > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/provision/document.php?docu ment_id=24631 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/provision/download.php/2463 1/pstc-spml2-errata-draft-05.doc > > > PLEASE NOTE: If the above links do not work for you, your email application > may be breaking the link into two pieces. You may be able to copy and paste > the entire link address into the address field of your web browser. > > -OASIS Open Administration >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]