- From: David Orchard <dorchard@bea.com>
- Date: Tue, 12 Sep 2006 09:17:41 -0700
- To: "Asir Vedamuthu" <asirveda@microsoft.com>, <public-ws-policy@w3.org>
Asir, 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 difficult. 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 attributes. 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. Cheers, Dave > -----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