Re: [Geopriv] common policy/ common policy caps schema issue

From: Xiaotao Wu ^lt;xiaotaow@cs.columbia.edu>
Date: Sun Jul 18 2004 - 10:48:01 EDT

I think for substitutionGroup, you may need to define an abstract
element/type as the 'base class'. For the real elements/types, the new
type should be defined as the 'xs:extension' of the base abstract type,
the new element should be defined as the 'substitutionGroup' as the base
abstract element.

See attached s1.xsd, s2.xsd, s3.xsd and test123.xml

s1 defines abstract type 'action' and 'ActionType', and a real action
        'reject' substitute 'action. The 'reject' action has the type
        'RejectAction', extended from the abstract 'ActionType'
   s1 also defines a 'root' element that can have a sequence of actions.
s2 imports s1, defines 'ring' action
s3 imports s1, defines 'accept' action.

test123.xml use all three schemas, and put all the actions from different
schemas into the 'root' element.

-Xiaotao

===========================================================
Name : Xiaotao Wu
Email : xiaotaow@cs.columbia.edu
Homepage : http://www.cs.columbia.edu/~xiaotaow
Phone : (212)939-7054, Fax: (801)751-0217
Phone-PC : (212)939-7133
SIP : sip:xiaotaow@conductor.cs.columbia.edu
Office : Room 506, Mudd building, West 120th
===========================================================

On Sun, 18 Jul 2004, Jonathan Rosenberg wrote:

> 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@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

Received on Sun, 18 Jul 2004 10:48:01 -0400 (EDT)

This archive was generated by hypermail 2.1.8 : Sun Jul 18 2004 - 10:59:33 EDT