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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: Issue 239 and UPA violation


I have taken a quick look at this, and at risk of exposing my ignorance here, I'm having difficulty seeing the problem. If there is a problem, it must have existed before (and probably applies elsewhere as well).

This is what the Mike's proposed change has:

   <complexType name="Filter">

        <sequence>

            <choice minOccurs="0" maxOccurs="unbounded">

                  <element ref="sca:eventTypes" />

                  <element ref="sca:body" />

            </choice>

            <any namespace="##other" processContents="lax" minOccurs="0"

                    maxOccurs="unbounded"/>

        </sequence>

        <anyAttribute namespace="##other" processContents="lax"/>

    </complexType>

Where sca:body and sca:eventTypes can be substituted, as follows:

<element name="body" abstract="true"/>

    <element name="body.XPath1" type="string" substitutionGroup="body"/>

The worry is that you could substitute something into body from a non-SCA namespace and that would violate the UPA constraint since you wouldn't be able to tell whether it was substituting for body or whether it was in the wildcard xs:any.

That's true, but in this case the thing we are substituting is in the SCA namespace, and so can't go in the xa:any slot.

 If there's a general rule that says that as soon as you open up something as a substitution group head then you run the risk of UPA (because people could substitute something they s           <sequence>

               <element ref="sca:documentation" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:interface" minOccurs="0"/>
               <element ref="sca:binding" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:callback" minOccurs="0"/>
               <element ref="sca:requires" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:policySetAttachment" minOccurs="0"  
                        maxOccurs="unbounded"/>              
               <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
            </sequence>houldn't) then don't we have a problem with things like this?

           <sequence>
               <element ref="sca:documentation" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:interface" minOccurs="0"/>
               <element ref="sca:binding" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:callback" minOccurs="0"/>
               <element ref="sca:requires" minOccurs="0"
                        maxOccurs="unbounded"/>
               <element ref="sca:policySetAttachment" minOccurs="0"  
                        maxOccurs="unbounded"/>              
               <element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
            </sequence>

If you were to substitute sca:callback for sca:binding then you would have a similar issue.

I'm hoping that there is something obvious I am missing here


Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








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