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

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

From: David Orchard <dorchard@bea.com>
Date: Tue, 12 Sep 2006 09:17:41 -0700
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C023FCE85@repbex01.amer.bea.com>
To: "Asir Vedamuthu" <asirveda@microsoft.com>, <public-ws-policy@w3.org>


Thanks for the survey, that's useful data.  However, in the places that
you find wildcard elements, how many have elements in the same namespace
next to the wildcard?  I posit that most of them do, making ##any

I'm also curious why you limited the scope of "simple extensibility
model" to just elements.  If you include attributes and elements, then
there is a mixture of extensibility, sometimes ##any, sometimes ##other.
I posit there is a different consistent extensibility model, sometimes
known as architecture, across XML specifications: Use ##any wherever
possible, ##other otherwise.  In our case, we can allow ##any.

I think the real crux of this issue is versioning of namespaces.  I
believe that re-using namespaces for new constructs, ie adding an
element or attribute in an existing namespace IFF it's compatible, is a
good namespace versioning policy.  That includes elements and

If your position is that re-using namespaces for new constructs is bad,
then why do we consistently have ##any for attributes?  There's an
inconsistency there.

Finally, I'm glad to see that we can both live with each others'
preferred position.  At least that means if there is a vote between the
2 positions, we can live with either result.


> -----Original Message-----
> From: Asir Vedamuthu [mailto:asirveda@microsoft.com] 
> Sent: Tuesday, September 12, 2006 6:42 AM
> To: David Orchard; public-ws-policy@w3.org
> Subject: 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 16:21:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:15 UTC