RE: ACTION 13 Namespace URI versioning policy

+1

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295



"David Orchard" <dorchard@bea.com> 
Sent by: public-ws-policy-request@w3.org
08/15/2006 07:17 PM

To
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-policy@w3.org>
cc

Subject
RE: ACTION 13 Namespace URI versioning policy






I thought it was clear it was the cardinality of elements (which btw 
distinguishes it from adding new elements and from attributes).  There is 
a value space of documents under old cardinality (vso) and under the new 
cardinality (vsn).  As long as vso is a superset of vsn, it's backwards 
compatible because all the old processors can process the new documents. 
 
However, we could do with a bit of analysis of our spec.
 
Imagine Chris and I both have ws-policy engines.  There's a cardinality 
change in an element.  Let's find one...  OperatorContentType isn't right, 
it's a bag.  Perhaps PolicyAttachment.  Let's pick AppliesTo, currently 
minOccurs="1", maxOccurs="1". 
 
Two scenarios: 1) reduce the minOccurs, 2) expand the maxOccurs; 3) 
Imagine that it's my policy store that does one of the changes. 
 
1. I reducethe minOccurs.  I can process all of Chris's documents, but he 
might not be able to process some of mine.
 
2. I expand the maxOccurs.  I can process all of Chris's documents, but he 
might not be able to process some of mine. 
 
What we have is backwards compatibility (newer consumer can consume all 
old productions) but not forwards compatibility. 
 
If we want forwards compatibility, we have to put in a processing model 
that allows him to ignore the extra stuff.  We could say that Applies to 
is minOccurs="1" and maxOccurs="unbounded", and that only the first 
occurance of AppliesTo will be consumed and the rest ignored.  Then my 
spec comes along and says for some reason the 2nd, if it exists, is used 
for xyz purpose BUT not required.  Now we have forwards compatibility. 
However, the problem is that this could break existing impls.
 
We have another scenario, reducing the choice of Policy or PolicyReference 
minOccurs from "1" to "0".  In which case, the same scenario.  I send 
Chris a policyAttachment without one of these, he breaks. 
 
The netnet is that reducing minOccurs or expanding maxOccurs is a 
backwards compatible but not forwards compatible change, and we only have 
a couple places where this could happen.
 
Cheers,
Dave
 
 

From: public-ws-policy-request@w3.org 
[mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Tuesday, August 15, 2006 1:47 PM
To: public-ws-policy@w3.org
Subject: ACTION 13 Namespace URI versioning policy

Folks, 
I have reviewed the namespace URI versioning policy that is currently 
stated in Section 2.2 per my action item[1].  
<snip/> 
2) It is not clear to me what "cardinality of elements" refer to in the 
fourth bullet:    
{Modifications to the cardinality of elements for which the value-space of 
possible instance documents conformant to the previous revision of the 
schema would still be valid with regards to the revised cardinality rule.}
Do we mean the cardinality of the value space or the occurance of the 
element (with minOccurs/maxOccurs)? The former is about the cardinality of 
the datatype of the element and should not be referred to the element 
cardinality? 
Chris? 
If I speculate the intention of the last bullet, I believe we are not 
really talking about value spaces here but perhaps trying to indicate that 
the occurance of the elements in the new schema should be covering the 
occurances of the instances of the same element in the old schema (ie. 0,n 
-> 0, n+1) 
I will be happy to help in formulating a better wording, but I think we 
need to clarify the intent of the fourth bullet first to proceed. 
Thanks, 
--umit 
[1] http://www.w3.org/2005/06/tracker/wspolicy/actions/13 
---------------------- 
Dr. Umit Yalcinalp 
Architect 
NetWeaver Industry Standards 
SAP Labs, LLC 
Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 
-------- 
"First they ignore you, then they ridicule you, 
then they fight you, then you win." Gandhi