<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
	targetNamespace="http://nj.oclc.org/uhfs" 	
	xmlns="http://nj.oclc.org/uhfs" 	
	elementFormDefault="qualified" 
	attributeFormDefault="qualified">
	<xsd:annotation>
		<xsd:documentation>Minimalist XML Schema for transmitting generic holdings data, thus "Universal Holdings Format" or UHF.  This version was published July 30, 2003.  

Author: Eric S. Hellman, eric@openly.com
Copyright (2002-2003) by Openly Informatics Inc.
All Rights Reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

    Redistributions of source  must retain the above copyright
    notice, this list of conditions and the following disclaimer. 

    Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in
    the documentation and/or other materials provided with the
    distribution.

    The name of the author may not be used to endorse or promote
    products derived from this specification without specific prior written
    permission. 

    The "UHF" name and logo may not be used to endorse or promote
    products derived from this specification without specific prior written
    permission of Openly Informatics, Inc.. 

THIS DOCUMENT TYPE DEFINITION IS PROVIDED ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
		</xsd:documentation>
	</xsd:annotation>
	<xsd:element name="uhf">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="header" minOccurs="0"/>
				<xsd:element ref="objects" minOccurs="0"/>
				<xsd:group ref="holdingItems" minOccurs="0" maxOccurs="unbounded"/> 
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="header">
		<xsd:annotation>
			<xsd:documentation>The optional header element is provided to accomodate metadata related to the  current document. Typical uses would be to enter time stamps, copyright notices, legal disclaimers, query echoes and message statistics.</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:any  minOccurs="0" maxOccurs="unbounded"/>
			</xsd:sequence>
			<xsd:anyAttribute namespace="##any"/>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="objects">
		<xsd:annotation>
			<xsd:documentation>The objects element can contain anything. It is provided to allow transport of objects within a document. Note that since the holding elements are empty, they can only have object attributes   through a reference. This reflects the design premise that a complex attribute must typically be described separately. For example, if the value of an "author" attribute is a person needing complex metadata (role, email, first name, last name, phone number, etc., then a sensibly designed information system should keep tract of people separately, and it makes no sense to keep the metadata for the author bound to the book. In UHF, the author attribute would be an object reference, and the object could be identified by URL, or by a reference to an object transported in the objects element. There must be a scheme declared for objects found in the objects element (a validating parser should check validity of elements that it contains. Note that objects are parsed before the holdings so that property references can be resolved immediately.</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:any minOccurs="1" maxOccurs="unbounded"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="collection">			
		<xsd:annotation>
			<xsd:documentation>A collection is a container that has things in it. The things are holdings or collections, or bunches of holdings or collections. A collection inherits any attribute of its parent, but does not bequeath attributes to its children.</xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="repetition" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:group ref="holdingItem" maxOccurs="unbounded"/> 
			</xsd:sequence>
			<xsd:anyAttribute namespace="##any"/>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="bunchof">			
		<xsd:annotation>
			<xsd:documentation>The bunchof element is a syntactic container. All attributes of the element are understood to apply to every element contained in the bunch. We say that it is a syntactic container to distinguish it from a real container, which can have attributes in its own right. Attributes inherited from a bunchof element are overridden when  </xsd:documentation>
		</xsd:annotation>
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element ref="repetition" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:group ref="holdingItem" maxOccurs="unbounded"/> 				
			</xsd:sequence>
			<xsd:anyAttribute namespace="##any"/>
		</xsd:complexType>
	</xsd:element>

	<xsd:element name="holding">			
		<xsd:complexType>
			<xsd:annotation>
				<xsd:documentation>A holding can only have attributes; the only content it can have is a repetition element which syntactically represents repeated attributes. Holding is an atom, In other words, UHF regards all things in a digital library to be either an atom or a collection of other things.</xsd:documentation>
			</xsd:annotation>
			<xsd:sequence>
				<xsd:element ref="repetition" minOccurs="0" maxOccurs="unbounded"/>
			</xsd:sequence>
			<xsd:anyAttribute namespace="##any"/>
		</xsd:complexType>
	</xsd:element>


	<xsd:element name="repetition">
		<xsd:complexType>
			<xsd:annotation>
				<xsd:documentation>Declared EMPTY. A repetition is a syntactic element that carries an attribute. It exists to allow holdings and collections to have multiple values for a given attribute. The parent element is considered to have an attribute value which is an array of the values carried by all the child repetition elements. This array value overrides any existing values, even if present in attributes of the parent. Repetition elements always come first in their parent elements.</xsd:documentation>
			</xsd:annotation>
			<xsd:anyAttribute namespace="##any"/>
		</xsd:complexType>
	</xsd:element>

	<xsd:attribute name="URL" type="xsd:anyURI">
		<xsd:annotation>
			<xsd:documentation>A uri to be used for linking to the holding or collection that it is attached to. URL is considered to be one of the very few attributes that must be natively defined in UHF. We use the name "URL" instead of the more generic "URI" out of simple nostalgia for the days when we understood the differences between URLs and URIs that were not URLs. </xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:attribute name="infoURL" type="xsd:anyURI">
		<xsd:annotation>
			<xsd:documentation>A uri to be used for linking to information about the holding or collection that it is attached to. We use the name "URL" instead of the more generic "URI" out of simple nostalgia for the days when we understood the differences between URLs and URIs that were not URLs.</xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:attribute name="internationalURL" type="xsd:string">
		<xsd:annotation>
			<xsd:documentation>A uri to be used for alternate linking by international users to the holding or collection that it is attached to. We use the name "URL" instead of the more generic "URI" out of simple nostalgia for the days when we understood the differences between URLs and URIs that were not URLs. Non-uri strings may be present as placeholders.</xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:attribute name="ID" type="xsd:ID">
		<xsd:annotation>
			<xsd:documentation>A local unique name for the holding or collection that is attached to this attribute. For use as the target of REF type attributes. Note the difference between ID, which is a local identifier, and URL, which can be a global identifier. </xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:attribute name="Ref" type="xsd:anyURI">
		<xsd:annotation>
			<xsd:documentation>When a holding or collection element has this attribute, it means that the element identified by the uri represents the same thing as the current element. This allows a holding to belog to multiple collections, for one thing. All metadata attributes for the represented thing should be attached to the target element. </xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:attribute name="Note" type="xsd:string">
		<xsd:annotation>
			<xsd:documentation>Annotation for a holding. </xsd:documentation>
		</xsd:annotation>
	
	</xsd:attribute>
	
	<xsd:group name="holdingItems">
		<xsd:choice>
			<xsd:element ref="collection"/>
			<xsd:element ref="bunchof"/>
		</xsd:choice>
	</xsd:group>
	
	<xsd:group name="holdingItem">
		<xsd:choice>
			<xsd:element ref="collection"/>
			<xsd:element ref="bunchof"/>
			<xsd:element ref="holding"/>
		</xsd:choice>
	</xsd:group>
	
</xsd:schema>
