[Simple] common policy/ common policy caps schema issue

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

Folks,

While revising draft-rosenberg-simple-common-policy-caps, I ran into an 
issue in the schema design which I believe affects the documents 
developed in both simple and geopriv that make use of the XML schema 
substitutionGroup concept.

The idea with a substitution group is that you could declare one element 
as a substitute for another. This would seemingly allow us to extend 
common policy or common policy caps with new policies/capabilities, and 
declare them to be conditions, actions, or transformations. And indeed, 
it does do this. However, there is a problem.

The problem is that, when you create such an extension, you need to 
create a new schema that includes these extensions, and then specify 
that documents have to compliant to this new schema. This creates a 
major problem in systems where you want to develop independent 
extensions to the schema. Let me give an example.

Lets say we have a base schema S1, which contains elements in the 
namespace N1. One group decides to add some new elements using 
substitution groups, so it creates schema S2, with elements in namespace 
N2 declared as substitutes for the right elements in S1. S2 will need to 
import S1, since the head element of the substitution group is defined 
there. Similarly, another group decides to add some new elements. So, it 
creates schema S3, with elements in namespace N3, declared as 
substitutes for elements in S1. S3 also imports S1, for the same reason.

Now, a server or client wish to implement both extensions. So, it 
creates a document with elements from N1, N2 and N3. Which schema is 
this document compliant to? None of them! Take a look at each in turn:

S1: the elements from N2 and N3 are in the instance document, but are 
not defined in S1. Since S1 was using substitution groups, it's schema 
doesn't have <xs:any namespace="##other" minOccurs="0" 
maxOccurs="unbounded"/> defined in its schema. Elements not defined in 
the schema cnanot be included. Thus, the document is not valid according 
to S1.

S2: The elements from N3 are not defined in S2. S2, like S1, won't have 
<xs:any> declarations, so these elements are not allowed and the 
docuemnt is not valid.

S3: The elements from N2 are not defined in S3. S3, like S1, won't have 
<xs:any> declarations, so these elements are not allowed and the 
docuemnt is not valid.


If we go ahead and add <xs:any> declarations to S1, we will allow any 
kind of element to be added, thus defeating the constraint that we 
wanted with the substitution group.

So, my conclusion was that substitution groups were useful in schemas 
where a single chain of extensions would be developed, and each new 
extension would include elements from the previous. Thus, you "extend" 
the schema by basically revising it and including new elements in the 
revised version. This is a valid model of extensibility in some 
environments, but I think we want a model that supports more distributed 
extensibility, where each extensions doesnt need to know about the other.

The only way I know to do this is to remove the usage of substitution 
groups, and use the <xs:any> construct. This does mean that the schema 
validation cannot verify that new conditions, actions or transformations 
are appropriately placed in the document. But, I think this is the price 
we need to pay for the extensibility we need.

Does anyone have a better idea?

Thanks,
Jonathan R.


--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple