Alternate schema

["Barnhill William" <barnhill_william@bah.com>]

<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema 
	targetNamespace="http://xdi.oasis-open.org"; 
	elementFormDefault="qualified" 
	xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
>
	<!-- Proposed changes -->
	<!-- 1. Schema extensibility
		The schema design pattern used is also sometimes referred to as Salami Slice, 
		because each type is a 'slice' thats put together using ref attributes. This 
		design pattern balances size and extensibility, but given the limited number 
		of element types, why not go for full extensibility and use the venetian blind 
		model, where each component is a type.
	-->
	<!-- 2. Comment element
		The comment annotation says it is only for human readable annotations and is completely
		ignored by XDI processors. If that's the case then what is the value of xdi:comment
		over xml comments? 
	-->
	<!-- 3. There seems to be two types of data elements, one that is XDI data, and one that is
		non-XDI data. To that end I'd propose reflecting this difference in the schema with the
		addition of a XDIdata element. 
	-->
	<!-- 4. All of the XDI elements (except for comment) are XRI addressable as I understood from
		discussions, but in the schema not all of them are. We can make this clearer by having
		an abstract type addressable and having addressable type extend it. I also had two
		other ideas relating to the addressing. The first is that it might be desirable
		to allow alternate forms of addressing to be represented as well, and so I've added
		an <addresses> element which can contain <xri> elements, and other non xdi elements. The
		other idea is that an address itself could, and probably often would be, a resource, so I
		added that possibility into <address>. There should however be at least one XDI address,
		so I've specified a mandatory xri or resource at the beginning of the addresses. This then 
		becomes the primary address. While in theory the beauty of having resources under address is
		attractive, I am not fully convinced the benefits outweigh storing statements about the
		address itself within the XDIattributes tree. I'm also not sure how you would address such
		resources..you have * for resources under XDIattributes, / for resources under XDIdata, but 
		for resources under addresses?
	-->
	<!-- 5. xri as string. I strongly agree with adding a pattern restriction, but it needs to be 
		created by someone who knows more than myself about XRI.
	-->
	<!-- 6. After the above changes we'd have possible child elements within resource of
		  (a) 1*addresses: which could be a container for resources
		  (b) Either 1*data: really the leaf of the XDI tree
		      or    1*XDIdata: a container for resources
		  (c) n*resources
              	It may just be my love of symmetry, but it seems that it might be useful for both readability
		and parsing if we have resource container element for child resources of a resource element.
		Based on the discussions of path navigation one candidate pops immediately to mind, <attributes>.
		Changing the name to match XDIdata we have XDIattributes
	  -->
	<xs:simpleType name="xri">
		<xs:restriction base="string">
			<xs:annotation>
				<xs:documentation>
					This element definition may be enhanced to include an XML pattern 
					element matching the XRI ABNF, so a standard XML schema validating 
					parser will be able to validate that an XRI value is legal.
				</xs:documentation>
			</xs:annotation>
		</xs:restriction>
	</xs:simpleType>

	<xs:complexType name="addresses">
		<xs:sequence>
	   		<xs:choice minOccurs="1" > 
				<xs:element name="xri" type="xri" />
				<xs:element name="resource" type="resource" />
			</xs:choice>
   			<xs:choice minOccurs="0" maxOccurs="unbounded" > 
				<xs:element name="xri" type="xri" />
				<xs:element name="resource" type="resource" />
   				<xs:any namespace="##other" processContents="strict"  />	
   				<xs:any namespace="##local" processContents="strict"  />
   			</xs:choice>
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="addressable" abstract="true">
		<xs:sequence>
			<xs:element name="addresses" type="addresses" minOccurs="1" maxOccurs="1"/>
		</xs:sequence>
	</xs:complexType>



	<xs:complexType mixed="true" name="data">
		<xs:complexContent>
	      		<xs:extension base="addressable">
 		  		<xs:choice minOccurs="0" maxOccurs="unbounded" > 
   					<xs:any namespace="##other" processContents="strict"  />	
   					<xs:any namespace="##local" processContents="strict"  />
   				</xs:choice>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>


	<xs:complexType  name="XDIdata">
		<xs:complexContent>
	      		<xs:extension base="addressable">
				<xs:sequence>
					<xs:element name="resource" type="resource" minOccurs="0" maxOccurs="unbounded"/>
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

	<xs:complexType  name="XDIattributes">
		<xs:complexContent>
	      		<xs:extension base="addressable">
				<xs:sequence>
					<xs:element name="resource" type="resource" minOccurs="0" maxOccurs="unbounded"/>
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

	<xs:complexType name="resource">
		<xs:complexContent>
	      		<xs:extension base="addressable">
				<xs:sequence>

					<!-- allow XDIdata or data, but not both -->
			   		<xs:choice minOccurs="0"> 
						<xs:element name="data" type="data" />
						<xs:element name="XDIdata" type="XDIdata" />
	   				</xs:choice>

					<!-- allow any element except those from target namespace -->
	   				<xs:choice minOccurs="0" maxOccurs="unbounded" > 
	   					<xs:any namespace="##other" processContents="strict"  />	
   	   					<xs:any namespace="##local" processContents="strict"  />
	   				</xs:choice>
					<xs:element name="XDIattributes" type="XDIattributes" minOccurs="0" />
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
</xs:schema>