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