I've updated issue 3590,
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3590 My latest comment
is:
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.