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
<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
<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