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

RE PolicyReference element extensibility

Not aware of any practical scenarios enabled by this point and level of
extensibility.

RE AppliesTo element extensibility

Not aware of any practical scenarios where one policy applies to another
policy or another external policy attachment element.


Here is a survey of wild card namespace constraints specified by several
Web service metadata specifications:

WSDL 1.1 uses ##other
WSDL 2.0 uses ##other
WS-SecurityPolicy uses ##other
WS-RM Policy uses ##other
WS-AT Assertion uses ##other
WS-BA Assertion uses ##other
WS-MetadataExchange uses ##other

To maintain consistency across all the metadata specs and have one
simple extensibility rule for all the elements in WS-Policy, our
preference is ##other for both PolicyReference and AppliesTo elements.
This is #3 in your list of options (below) for element extensibility. We
can live with #2.

I hope this helps.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
Sent: Friday, September 08, 2006 8:06 AM
To: public-ws-policy@w3.org
Subject: New issue(3662): Use of element wildcard ##any namespace vs
##other namespace


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 Tuesday, 12 September 2006 13:42:37 UTC