Re: [sca-assembly] Issue 239 and UPA violation

Thanks Mike and Anish for answering my
question and putting me straight here.

It seems that the schema as defined
by Mike is fine as far as it goes.. i.e. you can substitute in things like
sca:body.XPath1  without trouble. The issue is that third parties
can't add things from other namespaces because they would clash with the

 <any namespace="##other"
processContents="lax" minOccurs="0"
 maxOccurs="unbounded"/>

There are two kinds of extension that
need to be considered

i) Someone wants to define a new body
filter dialect, or eventTypes filter dialect.  

The natural way for them to do this is
to define their own element and put it in the appropriate substitution
group (just like we do). They can't do that at the moment because of the
xs:any. If we were just to remove the xs:any from the schema, then they
could do this just fine. 

ii) Someone wants to define a new kind
of filter, that isn't a body or eventTypes filter. 

It would be inappropriate for them to
substitute into either of the two filter elements that we have defined..
and that I think is the intention of having the xs:any there in the first
place. So if we were to remove the xs:any then they would no longer be
able to do this.

 Possible solutions

1. Replace xs:any with a ref to sca:extensions.
This is something we have done elsewhere and it would look like this..

<filter>

  <sca:body.XPath1>
aaa </sca:body.XPath1>

  <sca:extensions>

     <xxx:myFilter.myDialect>...</xxx:myFilter.myDialect>

  </sca:extensions>

</filter>

Anish has pointed out that this is unattractive since filters that are
logically ANDed together appear at different levels in the structure

2. Change the schema declaration of
the Filter complex type so that it includes a choice of the two filter
types we have defined, plus an exensibility place

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

           
      <element ref="sca:eventTypes" />

           
      <element ref="sca:body" />

           
     <element ref="sca:filterExtension" />

           
</choice> 

where sca:filterExtension is an abstract
GED which can be used as a substitution group head by someone wishing to
do a type ii) extension.  

This would keep all the filters at the
same level.. would it meet the UPA constraint? 

3. Don't use substitution groups at all
(as in Eric's original proposal). This means that there's no way (other
than external documentation) of telling whether a new filter is a body
filter, an event type filter or some other kind of filter.

Peter Niblett

IBM Senior Technical Staff Member

Member of the IBM Academy of Technology

From:      
 Peter Niblett/UK/IBM@IBMGB

To:      
 OASIS Assembly <>,

Date:      
 22/11/2011 15:21

Subject:    
   [sca-assembly]
Issue 239 and UPA violation

Sent by:    
   <>

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 shouldn'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 

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