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

[Peter Niblett <peter_niblett@uk.ibm.com>]

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 <sca-assembly@lists.oasis-open.org>,
Date:        22/11/2011 15:21
Subject:        [sca-assembly] Issue 239 and UPA violation
Sent by:        <sca-assembly@lists.oasis-open.org>

---

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