W3C home > Mailing lists > Public > public-ws-policy@w3.org > August 2006

Updated issue 3590

From: David Orchard <dorchard@bea.com>
Date: Mon, 28 Aug 2006 14:29:42 -0700
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C02298B15@repbex01.amer.bea.com>
To: <public-ws-policy@w3.org>

I've updated issue 3590,
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3590  My latest comment

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

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

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

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:ExactlyOne newns:Attrib="true">
    <!-- assertion 1 -->
    <!-- assertion 2 -->
  <wsp:ExactlyOne newns:Attrib="false">
    <!-- assertion 3 -->
    <!-- assertion 4 -->

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>

Another example is the associative rule:
  <!-- assertion 1 -->
  <wsp:All> <!-- assertion 2 --> </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

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

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.
Received on Monday, 28 August 2006 21:30:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:27 UTC