[Adding discussion from the mailing list]
URI: http://lists.w3.org/Archives/Public/public-ws-policy/2006Aug/0108.html

> The remaining places may not be extensible by design

The extensibility points in the WS-Policy Framework [1] are:

wsp:Policy/{any}
wsp:ExactlyOne/{any}
wsp:All/{any}

wsp:Policy/@{any}
wsp:PolicyReference/@{any}

Per extensibility WS-Policy Extensibility model [2], if an EII is not recognized, it should be treated as an assertion; if an AII is not recognized, it should be ignored.

[1] See XML Schema for WS-Policy
[2]
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.h
tml?content-type=text/html;%20charset=utf-8#Extensibility 

Regards,
 
Asir S Vedamuthu
Microsoft Corporation

Policy framework defines a number of elements, each of which could potentially have extensibility points for attributes and elements.   

Every place where extensibility can occur, each such extensibility should be
documented.  The attachment document and other WS-* documents typically follow a form for elements and attributes that use XPath notation.  An attribute example is:
/XYZ/@{any} The description of attribute extensibility from attachments is typically:
Additional attributes MAY be specified but MUST NOT contradict the semantics of
the owner element; if an attribute is not recognized, it SHOULD be ignored.

The following extension points are documented as extensions that can be <assertions>, no change is needed:
1. wsp:Policy/{any}
2. wsp:ExactlyOne/{any}
3. wsp:All/{any}

The elipses notation shows extensibility in:
4. /wsp:Policy/@{any}
5. /wsp:Policy//wsp:PolicyReference/@{any}

These are now documented in Framework using XPath notation consistent with Attachment.

However, the attribute extensibility defined in Attachment then copied to Framework does not allow attributes from the ws policy namespace.  This restriction is unnecessary because attributes don't have the UPA restrictions that elements have.

I propose the attribute extensibility should be for attributes for any namespace.

The following are the remaining possible extensibility points, not currently defined as being extensible:
6. /wsp:Policy//wsp:PolicyReference/{any}

7. /wsp:Policy/wsp:ExactlyOne/@{any}
8. /wsp:Policy/wsp:ExactlyOne/wsp:All/@{any}

Let us now examine each of these.

The Framework document roughly states that a PolicyReference Element is replaced by the referent document.  Which means any child element needs treatment of some kind.  The simplest is to throw away any unknown child.  

We can examine other inclusion mechanisms for their allowance and treatment of child elements:
XInclude- Allows element extensibility for ##other and ##local and defines current namespace fallback child element
XSD Include- I *think* this allows element exts but maybe just <annotation> elements
XSD Import- allows element exts, maybe just <annotation> elements
WSDL Include/Import- Allows element exts in ##other ns.

There is clear precedence for element extensibility in include/import mechanisms.  There may be reasons why a PolicyReference may want element children, subject to the processing model rules such as ignore.  Documentation and Fallback are 2 that are used in the list above.

Because any PolicyReference element extensibility would not have a UPA conflict (as Policy isn't defining any content) the PolicyReference should have namespace ##any.

I propose we add element extensibility to PolicyReference and document that any unknown elements will be ignored.  I propose that the extensibility is for any namespace.  

ExactlyOne and All are processed during normalization and have various rules defined for them.  These rules would need updating to deal with attribute extensibility.  In some cases, this may be impossible. For example, the associative rule for <All><ExactlyOne><Assert1/><Assert2> would need updating.  Looking at this example futher, imagine a binary attribute was added to the first and second ExactlyOne, as in

<wsp:All>
  <wsp:ExactlyOne newns:Attrib="true">
    <!-- assertion 1 -->
    <!-- assertion 2 -->
  </wsp:ExactlyOne>
  <wsp:ExactlyOne newns:Attrib="false">
    <!-- assertion 3 -->
    <!-- assertion 4 -->
  </wsp:ExactlyOne>
</wsp:All>

This could be mapped to
<wsp:ExactlyOne newns:Attrib="?">
  <wsp:All><!-- assertion 1 --><!-- assertion 3 --></wsp:All>
  <wsp:All><!-- assertion 1 --><!-- assertion 4 --></wsp:All>
  <wsp:All><!-- assertion 2 --><!-- assertion 3 --></wsp:All>
  <wsp:All><!-- assertion 2 --><!-- assertion 4 --></wsp:All>
</wsp:ExactlyOne>

Another example is the associative rule:
<wsp:All>
  <!-- assertion 1 -->
  <wsp:All> <!-- assertion 2 --> </wsp:All>
</wsp:All>

One option would be to specify that any attributes will be transformed in certain ways and they shouldn't conflict after normalization.  This seems difficult to specify and potentially significant implementation cost.

I propose no change to attribute extensibility on All/ExactlyOne.  

Overall, I propose that:
1. The same notation conventions from the attachment document be included in
framework.  Now done(8/28/06).  Note, this may need some touching up as the Element extensibility notation is documented but may not be used, pending this issue resolution for PolicyReference element extensibility.

2. The Policy and PolicyReference attribute extensibility points (Policy/@{any} and PolicyReference/@{any}) are now documented (8/28/06).  

3. The attribute extensibility should be for attributes for any namespace

4. The PolicyReference Element is modified to add an element extensibility point.  This should be for any namespace, which means a slight change to the notation section.  This includes specifying that unknown element child content is ignored.

> 3. The attribute extensibility should be for attributes for any namespace
> 4. The PolicyReference Element is modified to add an element extensibility
> point.  This should be for any namespace, which means a slight change to the
> notation section.  This includes specifying that unknown element child content
> is ignored.


#3 was agreed to by WG
#4 is agreed to by WG, but element extensibility of ##other vs ##any is decided in 3662

See anchor: http://www.w3.org/2006/09/13-ws-policy-irc#T16-41-41
See meeting minutes at http://www.w3.org/2006/09/13-ws-policy-irc

Approved #4 (except for portion in #3662) 13 September 2006.