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

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