[Bug 4197] Inconsistency on treatment of unknown extensibility elements (Framework, Primer, Guidelines)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197

           Summary: Inconsistency on treatment of unknown extensibility
                    elements (Framework, Primer, Guidelines)
           Product: WS-Policy
           Version: LC
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: monica.martin@sun.com
         QAContact: public-ws-policy-qa@w3.org


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 doesn’t flow well with the remainder of the paragraph.
So we’ve 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)

Received on Friday, 12 January 2007 01:12:13 UTC