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

New issue(3662): Use of element wildcard ##any namespace vs ##other namespace

From: David Orchard <dorchard@bea.com>
Date: Fri, 8 Sep 2006 08:06:05 -0700
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C023FC53C@repbex01.amer.bea.com>
To: <public-ws-policy@w3.org>

Title: Use of element wildcard ##any namespace vs ##other namespace

Description:
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 Friday, 8 September 2006 15:06:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:41 GMT