[Bug 3662] Use of element wildcard ##any namespace vs ##other namespace

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

           Summary: Use of element wildcard ##any namespace vs ##other
                    namespace
           Product: WS-Policy
           Version: PR
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework+Attachment
        AssignedTo: fsasaki@w3.org
        ReportedBy: orchard@pacificspirit.com
         QAContact: public-ws-policy-qa@w3.org


WS-Policy Framework and attachment define a number of elements with element
extensibility.  Where the extensibility is provided, the form is for elements
from ##other namespace.  The elements with their current element extensibility
is:

Policy: element from ##other namespace
PolicyReference: None, with a proposal to add any element, the use of ##other
vs ##any spawned this issue.
ExactlyOne, All: element from ##other namespace
PolicyAttachment:  element from ##other namespace
AppliesTo: element from ##any element

Policy, ExactlyOne, All, PolicyAttachment all of have optional children defined
in their content model.  Interestingly, the PolicyAttachment would like to
refer to wsse:Security but it can't because of a UPA conflict between the
##other and wsse:Security.  There already is an example of where an element
reference is omitted from the schema because of a UPA violation.

AppliesTo allows element from ##any namespace.  Interestingly, it's not clear
what an AppliesTo that had an element from WS-Policy ns would mean.  

All the elements that have attribute exensibility have ##any attribute
extensibility.  

There is a separate issue, 3590, to add element extensibility to
PolicyReference.  This brings up the issue of which namespace should it be,
##any or ##other.  

An argument has been made that ##other is the consistent approach for
extensibility in metadata specs.  That precludes the creation of new names in
the current namespace.  

My counter argument is that the extensibility architecture is actually:
1) Use ##any for all extensibility where possible,
2) else use ##other.
3) Where ##other conflicts with a particular element, remove the element from
the content model.

In the case of PolicyReference, there are no optional elements in the target
namespace, therefore ##any should be used.

Given that ##any is used for attribute extensibility, which means a new
attribute name can be added into the existing WS-Policy namespace, I don't see
why a new element name can't be added.  

There is another alternative approach that is consistent, which is to have all
the elements have ##any namespace including exactlyOne and All, and then remove
those elements from the pertinent content models, ala wsse:Security
nonInclusion.

One key question is how much of the validation of Policy element content is
done by schema validation versus custom Policy logic.  There are many rules
defined for processing Policy constructs above and beyond the arguably
simplistic schema constraints.  I tend to think the schema is not terribly
constraining or useful.  

I see 3 options for element extensibility:
1. Use ##any and remove all optional element refs.  
2. Use ##any where possible, ##other elsewise, remove all ##other optional
element refs.
3. Use ##other everywhere, remove all ##other optional element refs.

I can live with any of these, and order of preference is #2, #1, #3.

Received on Wednesday, 6 September 2006 18:58:19 UTC