RE: 3617 - ACTION 13 Namespace URI versioning policy

Let me summarize this thread:

 

1. Doesn't hurt to retain the third bullet.

2. Umit's suggestion - drop "or for which the value-space of the
preponderance of instance would remain valid".

3. Umit's request - clarify 'cardinality of elements'.

 

Here is a concrete proposal to resolve 3617:

 

Re bullet 1: No change is necessary

Re bullet 2: s/ or for which the value-space of the preponderance of
instance would remain valid//.

Re bullet 3: s/cardinality of elements/cardinality of elements (i.e.
modifications to minOccurs or maxOccurs attribute value of an element
declaration)/.

 

Regards,

 

Asir S Vedamuthu

Microsoft Corporation

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B
Ferris
Sent: Wednesday, August 16, 2006 6:04 AM
To: public-ws-policy@w3.org
Subject: 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
<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