This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4197 - Inconsistency on treatment of unknown extensibility elements (Framework, Primer, Guidelines)
Summary: Inconsistency on treatment of unknown extensibility elements (Framework, Prim...
Status: RESOLVED FIXED
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Framework (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Monica Martin
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-12 01:12 UTC by Monica Martin
Modified: 2007-01-16 23:39 UTC (History)
0 users

See Also:


Attachments

Description Monica Martin 2007-01-12 01:12:03 UTC
Title: Inconsistency on treatment of unknown extensibility elements
Target: Framework, Primer and Guideline documents

Description:
The Framework specification specifies treatment of unknown extensibility elements and attributes. As stated in Section 2.2 Extensibility in the Framework:

"Within normative outlines, ellipses (i.e., "") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. If an Attribute Information Item is not recognized, it SHOULD be ignored; if an Element Information Item is not recognized, it MUST be treated as an assertion."

Yet, sections in the Framework and PolicyAttachments document also specify that unknown extensibility elements will be ignored, such as:

Framework, Section 4.3.4 Policy Reference
/wsp:PolicyReference/{any}
Additional elements MAY be specified but MUST NOT contradict the 
semantics of the [parent element]; if an element is not recognized, it 
SHOULD be ignored.

PolicyAttachment, 3.4 External Policy Attachment
/wsp:PolicyAttachment/wsp:AppliesTo/{any}
These child elements MUST specify and/or refine the domain expression(s) 
that define the policy scope. They MUST NOT contradict the semantics of 
their root element; if an element is not recognized, it SHOULD be ignored.

/wsp:PolicyAttachment/{any}
Other child elements for binding constructs MAY be specified but MUST 
NOT contradict the semantics of the parent element; if an element is not 
recognized, it SHOULD be ignored.

Similar examples apply for the Primer and Guidelines.

Conceivably, Section 2.2 Framework implies that an unknown child element of wsp:Policy, wsp:ExactlyOne, or wsp:All is treated as a policy 
assertion. Other more specific references across all these documents imply unknown elements are ignored. However, Section 2.2 in its current 
form is ambiguous. Therefore, the behavior expected should be clarified as treating as a policy assertion and ignoring an element imply 
different expectations.

Justification: Clear understanding of treatment and processing required for unknown extensibility elements.

Proposal:

>>FRAMEWORK
Clarify the expected behavior in Section 2.2, Framework.

Section 2.2 Extensibility in the Framework:
Change from:
Within normative outlines, ellipses (i.e., "") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. If an Attribute Information Item is not recognized, it SHOULD be ignored; if an Element Information Item is not recognized, it MUST be treated as an assertion.

Change to:
Within normative outlines in this specification, ellipses (i.e., "") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension.

In this context, if an Attribute Information Item is not recognized, it SHOULD be ignored. And, if an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise.

>>POLICYATTACHMENT
None

>>PRIMER AND GUIDELINES
Given the decision on the Framework changes, the following sections require redress in the Primer and Guidelines.

Primer, Section 3.8, Extensibility and Versioning
Change from:
Web Services Policy language is an extensible language by design. The Policy, ExactlyOne, All and PolicyReference elements are extensible. The Policy, ExactlyOne and All elements allow child element and attribute extensibility. Extensions must not use the policy language XML namespace name. A consuming processor processes known attributes and elements, ignores unknown attributes and treats unknown elements as policy assertions.

The PolicyReference element allows element and attribute extensibility.

Change to:
Web Services Policy language is an extensible language by design. The Policy, ExactlyOne, All and PolicyReference elements are extensible. 

The |Policy| element allows child element and attribute extensibility, while |ExactlyOne| and |All| allow child element extensibility. 
The PolicyReference child element allows element and attribute extensibility.

Extensions must not use the policy language XML namespace name.

(new paragraph) A consuming processor processes known attributes and elements, ignores unknown attributes and treats unknown children of the Policy, All and ExactlyOne elements as policy assertions. The child elements of wsp:PolicyReference are ignored.

Change from:
Let us look at tooling for unknown policy assertions. As service providers, like Contoso, incrementally deploy advanced behaviors, some requesters may not recognize these new policy assertions. As discussed before, these requesters may continue to interact using old policy alternatives. New policy assertions will emerge to represent new behaviors and slowly become part of everyday interoperable interaction between requesters and providers. Today, most tools use a practical tolerant strategy to process new or unrecognized policy assertions. These tools consume such unrecognized assertions and designate these for user intervention.

Change to:
Let us look at tooling for unknown policy assertions. As service providers, like Contoso, incrementally deploy advanced behaviors, some requesters may not recognize these new policy assertions. As discussed before, these requesters may continue to interact using old policy alternatives. New policy assertions will emerge to represent new behaviors and slowly become part of everyday interoperable interaction between requesters and providers. For example, most tools use a practical tolerant strategy to process new or unrecognized policy assertions. These tools consume such unrecognized assertions and designate these for user intervention.

Primer, Section 3.10.1, Policy Framework
Change from:
WS-Policy Framework 1.5 specifies that any element that is not known inside a Policy, ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false", which means after normalization it will be inside an ExactlyOne/All operator.

Change to:
WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy, ExactlyOne, or All will be treated as an assertion.

The default value for wsp:Optional="false".  After normalization, such an element will be inside an ExactlyOne/All operator.

Note: The first sentence doesnt flow well with the remainder of the paragraph. So weve broken apart from succeeding sentence. This is purely editorial.

Primer, Section 3.10.2, PolicyAttachment
Change from:
The PolicyReference element is attribute extensible.

Change to:
The PolicyReference element is element or attribute extensible.

Note: Missed when #3966 was vetted.

Guidelines, Section 5, Lifecycle of Assertions
Change from:
...The current WS-Policy language Web Services Policy Framework <link> provides extensibility points on 6 elements with a combination of attribute and/or element extensibility:

1. Policy: element from ##other namespace and any attribute
2. PolicyReference: any attribute and a proposal to add any element
3. ExactlyOne, All: element from ##other namespace, no attribute extensibility
4. PolicyAttachment: element from ##other namespace and any attribute
5. AppliesTo: any element and any attribute

Change to:
...The current WS-Policy language Web Services Policy Framework <link> provides extensibility points on 6 elements with a combination of attribute and/or element extensibility:

1. Policy: element from ##other namespace and any attribute
2. ExactlyOne, All: element from ##other namespace, no attribute extensibility
3. PolicyReference: any element and any attribute
4. PolicyAttachment: element from ##other namespace and any attribute
5. AppliesTo: any element and any attribute
6. URI: any attribute

Note: The namespace question related to extensibility is handled in a separate issue.

References
Editor's copies and CVS area 10 January 2006: http://www.w3.org/2002/ws/policy 
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8 (Framework)
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;%20charset=utf-8#lifecycle (Guidelines)
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8#combine-policies (Primer)
Comment 1 Monica Martin 2007-01-12 01:14:20 UTC
See: http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0079.html

An .htm version of the changes with yellow highlighted text is attached to this email for Issue 4197.
Comment 2 Christopher Ferris 2007-01-16 23:39:34 UTC
RESOLUTION 4197 closed with changes in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/att-0079/wspolicy-extensibility-011007.htm__charset_WINDOWS... and change as " If an Attribute Information Item is not recognized, it SHOULD be ignored. If an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise such as in Section 4.3.4 Policy References <hyperlink>"

See http://www.w3.org/2007/01/16-ws-policy-irc#T23-38-45