Assembly 239 action item

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

I had an AI to write up Anish's proposal
on issue 239.  To set some context I will start with a couple of examples,
showing what the SCDL file looks like, and then I will show the current
proposal for the schema followed by Anish's variant. Note that Anish's
proposal only relates to the way we set out the XML Schema. It doesn't
alter what goes in the SCDL file itself

Example 1:

We will start with 2 Filters.. a Body
filter (using the only SCA-defined dialect, which is XPath1), an Event
type filter (using the only SCA-defined dialect which is a QName).

Assuming we have set up http://docs.oasis-open.org/ns/opencsa/sca/200912
as the default namespace, this would look like this:
<filters>
        <eventTypes.sca
qnames="myNS:myEventType">
           
<body.XPath1> a/b/c </body.XPath1> 
</filters>

Example 2:

Now let's suppose that implementation
foo wishes to offer an XPath2 body filter, and someone wants to use that
instead of the XPath1. We've agreed that the new filter will be in vendor
foo's namespace and will go in the same place as the body.XPath1 in the
above example. So we could have something like this

<filters>
        <eventTypes.sca
qnames="myNS:myEventType">
           
<foo:XPath2filter> a/b/c </foo:XPath2filter> 
</filters>

We don't have any control over what the vendor might choose to call their extension. In this example they have chosen a name that suggests it uses the XPath2 langage, but doesn't indicate that it's a body filter. The current proposal provides a mechanism (admittedly a bit obscure) by which they can indicate this via a Schema extension.

Current Proposal

A. In the current proposal for 239, the schema for <filters> looks like this:

    <element name="filters" type="sca:Filter"/>
    <complexType name="Filter">
        <choice minOccurs="0" maxOccurs="unbounded">
            <element ref="sca:eventTypes" />
            <element ref="sca:body" />
            <element ref="sca:filterExtension" />
        </choice>
        <anyAttribute namespace="##other" processContents="lax"/>
    </complexType>

B. ...where the three referenced elements are abstract substitution group heads...

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

C. We also  provide concrete definitions for an eventType and a body filter (these are the built-in SCA filters that appear in example 1)...

<element name="eventTypes.sca" type="sca:EventType.sca" substitutionGroup="eventTypes"/>
<element name="body.XPath1" type="string" substitutionGroup="body"/>

D. The idea is that in example 2 the third party would add <foo:XPath2filter> into the body substitution group, to indicate that it's a form of body filter. If it were a form of filter that is neither an event type filter nor a body filter, then it would go in the filterExtension substitution group.

Anish's alternative proposal

Anish has proposed an alternative way to lay out the schema - although he says he does not feel strongly about it.  In this version, the built-in filters (eventTypes.sca and body.XPath1) appear directly in the declaration of the Filter complex type, rather than appearing as substitution group members. So contrasting with the previous section,

A'.  The schema for <filters> looks like this:

      <element name="filters" type="sca:Filter"/>
      <complexType name="Filter">
         <choice minOccurs="0" maxOccurs="unbounded">
             <element ref="sca:eventTypes.sca" />
             <element ref="sca:body.XPath1" />
        </choice>
        <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs='unbounded'/>
        <anyAttribute namespace="##other" processContents="lax"/>
    </complexType>

B'   There are no abstract element declarations or substitution groups, instead...

C'   The built-in filters are declared as regular GEDs, not substitution group members

<element name="eventTypes.sca" type="sca:EventType.sca"/>
<element name="body.XPath1" type="string" />

D'  Any third party filters are just inserted where the xs:any appears in the Filter complex type declaration.

Commentary

The alternative proposal is simpler as it avoids the additional substitution groups. However

a) It doesn't allow people to indicate the nature of a new filter by contributing it to the appropriate substitution group (though to be fair there's no method of enforcing this with the existing proposal)

b) As far as I am aware, everywhere else that the . construct appears in an SCA element name it is associated with a substitution group.

Regards

Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)

---

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