Subject: [Simple] common policy/ common policy caps schema issue

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Jul 2004 09:12:19 -0400

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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Xiaotao Wu <[email-masked]>
Date: Sun, 18 Jul 2004 10:48:01 -0400 (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     : [email-masked]
Homepage  : http://www.cs.columbia.edu/~xiaotaow
Phone     : (212)939-7054,  Fax: (801)751-0217
Phone-PC  : (212)939-7133
SIP       : sip:[email-masked]
Office    : Room 506, Mudd building, West 120th
===========================================================

On Sun, 18 Jul 2004, Jonathan Rosenberg wrote:

> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 2004 12:12:20 -0400

Xiaotao,

You are correct, this can work.

I was using an abstract element in my base namespace. I had in my head 
that a document could only be compliant to a single schema, as opposed 
to compliant to the various schemas that define the elements used in the 
instance document. When I tried to provide multiple namespace/schemas in 
the schemaLocation, I got an error. Not sure why.

I'll switch the common-policy-caps document back to using substitution 
groups.

Thanks!

-Jonathan R.

Xiaotao Wu wrote:

> ------------------------------------------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Xiaotao Wu (Columbia University Computer Science Dept) -->
> 
> <xs:schema elementFormDefault="qualified" attributeFormDefault="unqualified" targetNamespace="xml:N1" xmlns="xml:N1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
> 
>   <xs:complexType name="ActionType" abstract="true"/>
> 
>   <xs:complexType name="RejectAction">
> 
>     <xs:complexContent>
> 
>       <xs:extension base="ActionType">
> 
>         <xs:attribute name="status" type="xs:string" use="required"/>
> 
>         <xs:attribute name="reason" type="xs:string" use="optional"/>
> 
>       </xs:extension>
> 
>     </xs:complexContent>
> 
>   </xs:complexType>
> 
>   <xs:element name="reject" type="RejectAction" substitutionGroup="action"/>
> 
>   <xs:element name="action" type="ActionType"/>
> 
>   <xs:element name="root">
> 
>     <xs:complexType>
> 
>       <xs:sequence>
> 
>         <xs:element ref="action" minOccurs="1" maxOccurs="unbounded"/>
> 
>       </xs:sequence>
> 
>     </xs:complexType>
> 
>   </xs:element>
> 
> </xs:schema>
> 
> 
> ------------------------------------------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Xiaotao Wu (Columbia University Computer Science Dept) -->
> <xs:schema targetNamespace="xml:N2" xmlns="xml:N2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:N1="xml:N1" elementFormDefault="qualified" attributeFormDefault="unqualified">
>   <xs:import namespace="xml:N1" schemaLocation="s1.xsd"/>
>   <xs:complexType name="DRingAction">
>     <xs:complexContent>
>       <xs:extension base="N1:ActionType">
>         <xs:attribute name="ringstyle" type="xs:string" use="optional"/>
>       </xs:extension>
>     </xs:complexContent>
>   </xs:complexType>
>   <xs:element name="ring" type="DRingAction" substitutionGroup="N1:action"/>
> </xs:schema>
> 
> 
> ------------------------------------------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Xiaotao Wu (Columbia University Computer Science Dept) -->
> <xs:schema targetNamespace="xml:N3" xmlns="xml:N3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:N1="xml:N1" elementFormDefault="qualified" attributeFormDefault="unqualified">
>   <xs:import namespace="xml:N1" schemaLocation="s1.xsd"/>
>   <xs:complexType name="AcceptAction">
>     <xs:complexContent>
>       <xs:extension base="N1:ActionType">
>         <xs:attribute name="media" type="xs:string" use="optional"/>
>       </xs:extension>
>     </xs:complexContent>
>   </xs:complexType>
>   <xs:element name="accept" type="AcceptAction" substitutionGroup="N1:action"/>
> </xs:schema>
> 
> 
> ------------------------------------------------------------------------
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Xiaotao Wu (Columbia University Computer Science Dept) -->
> <root xmlns="xml:N1" xmlns:N2="xml:N2" xmlns:N3="xml:N3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="xml:N1 s1.xsd 
>          xml:N2 s2.xsd
>          xml:N3 s3.xsd">
>   <N2:ring ringstyle="normal"/>
>   <N3:accept media="audio"/>
>   <reject status="busy"/>
> </root>
> ?