Re: [provision] Groups - SPML Errata Draft 5(pstc-spml2-errata-draft-05.doc) uploaded

["Gary.P.Cole" <Gary.P.Cole@Sun.COM>]

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?document_id=24631
>
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/provision/download.php/24631/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
>