← Prev in month ← Prev in thread

Issue 239 and UPA violation

From
Peter Niblett <>
Date
2011-11-22T15:14:30+00:00
ID
Thread
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
← Prev in month ← Prev in thread