Abstract

IXF is an XML-based format for describing a collection of objects and associated files that conform to a specific data model. IXF is used to exchange this data between systems.

A specific data model is described using an IXF Schema Document. An IXF Instance Document contains a set of objects and files that conform to the data model described in an associated IXF Schema Document.

An IXF Instance Document may also contain:

Description of previous revisions of the objects
Change-tracking information
Object hierarchies and relationships
Schema of the contained objects

Most elements of IXF can be extended and customized in a decentralized manner by any one or more parties.

Status

This document has been reviewed by the IXF Committee and other interested parties and has been endorsed by the IXF Committee as a Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document.

The list of known errors in this specification is available at http://www.ixfstd.org/std/docs/1.0/ixf-errata.

Please report errors in this document to yanivg@smarteam.com.

1.1 Overview of IXF. 7

1.2 Relation to existing standards. 7

1.3 Notational Conventions. 8

1.3.1 Keywords. 8

1.3.2 Namespaces. 8

1.3.3 URI Versioning Convention. 8

1.3.4 Syntax. 9

2. Definitions. 10

2.1 Attribute Definition.. 10

2.2 Must-Understand Indication Definition.. 11

2.3 Class Behavior Definition.. 11

2.4 Class Definition.. 12

2.4.1 Parent Class. 12

2.4.2 Class Behaviors. 13

2.4.3 Class Attributes. 13

2.4.4 Class Primary Attributes. 13

2.5 Domain Behavior Definition.. 13

2.6 InfoItem Definition.. 14

2.7 Schema Definition.. 15

2.8 Object Definition.. 15

2.8.1 Object Class. 16

2.8.2 Object ID.. 16

2.8.3 Attribute Values. 16

2.9 Instance Document Definition.. 16

2.10 Attribute Data Types. 16

3. Syntax.. 19

3.1 Syntax Overview... 19

3.2 Schema Document Syntax.. 19

3.2.1 The ixf:dataModelRole Attribute. 19

3.2.2 Existing Schemas. 19

3.2.3 Sample IXF Schema Document 19

3.3 Attribute Syntax.. 21

3.4 Class Behavior Syntax.. 24

3.5 Class Syntax.. 25

3.6 Domain Behavior Syntax.. 26

3.7 InfoItem Syntax.. 27

3.8 Instance Document Syntax.. 28

3.9 Object Syntax.. 28

4. Standard Behaviors. 30

4.1 Time Stamping.. 30

4.1.1 Class Behaviors. 30

4.1.2 Domain Behaviors. 31

4.2 Change Tracking.. 31

4.2.1 Class Behaviors. 32

4.2.2 Domain Behaviors. 35

4.3 File Association.. 35

4.3.1 Class Behaviors. 36

4.3.2 Domain Behaviors. 38

4.4 Versioning.. 39

4.4.1 Class Behaviors. 39

4.4.2 Domain Behaviors. 39

4.5 Links. 39

4.5.1 Class Behaviors. 40

4.5.2 Domain Behaviors. 41

5. Packaging Formats. 42

5.1 IXF Archive.. 42

5.2 IXF Message Package.. 42

6. Appendix – Mapping iXF Datatypes to Programming Languages Types. 44

6.1 Mapping Datatypes to COM Variant types. 44

6.2 Mapping Datatypes to Java types. 45

6.3 XML Attributes. 46

7. Appendix – IXF XSD Schemas. 47

7.1 IXF Core Schema.. 47

7.2 Standard Behavior Schemas. 49

7.2.1 Time Stamping. 49

7.2.2 Change Tracking. 49

7.2.3 File Association. 51

7.2.4 Versioning. 52

7.2.5 Links. 53

8. References. 55

1. Introduction

1.1 Overview of IXF

IXF is an XML-based format for describing a collection of objects and associated files that conform to a specific data model. IXF is used to exchange this data between systems.

IXF provides a formal method for expressing a specific subset of data models using XML and XML Schemas. The subset of data models supported by IXF is the collection of data models that can be expressed using objects, classes and behaviors.

A specific Data Model is described using an IXF Schema Document.

An IXF Instance Document contains a set of objects that conform to the Data Model described in the corresponding associated IXF Schema Document.

The data types supported by IXF are the data types that can be mapped accurately to common Programming Languages and standard Relational Database systems.

In addition, IXF specifies mechanisms providing the following features:

· Associating objects with specific files

· Tracking changes to a collection of objects

· Expressing relationships between objects

· Stamping objects with time and version related information

· Packaging schema, objects and related files

· Embedding custom information in the IXF Instance and Schema documents

Most of these features are implemented using standard IXF Objects with specific, standard behaviors.

1.2 Relation to existing standards

The IXF specification refers to and relies on several existing standards:

1.3 Notational Conventions

1.3.1 Keywords

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.3.2 Namespaces

The following namespace prefixes are used throughout this document:

Prefix	URI	Namespace definition
xsi	http://www.w3.org/2001/XMLSchema-instance	Instance namespace as defined by XSD.
xsd	http://www.w3.org/2001/XMLSchema	Schema namespace as defined by XSD.
ixf	http://www.ixfstd.org/std/ns/core/1.0	IXF Core namespace.
soap	http://schemas.xmlsoap.org/soap/envelope/	SOAP Envelope namespace.
tns	(various)	The “this namespace” (tns) prefix is used as a convention to refer to the current document.
(oth)	(various)	All other namespace prefixes are samples only. In particular, a URI starting with “http://example.com” represents an application-dependent or context-dependent URI.

1.3.3 URI Versioning Convention

By convention, all IXF-related URIs specified in this document end with a version number (currently 1.0). It should be noted that future versions of this specifications may define new URIs with a version number that is different from the version number of the specification as a whole, that is, each URI is versioned independently.

Also, the inclusion of a major.minor (e.g. 1.0) versioning scheme does not carry any significance with regards to compatibility between two versions of a specific URI-named feature. Meaning, two URIs that differ only in the minor version are just as different as two completely different URIs. Future versions of this specification may also define URIs which use a different versioning convention.

1.3.4 Syntax

This specification uses an informal syntax to describe the XML grammar of an IXF document:

The syntax appears as an XML instance, but values written in italics indicate the data types instead of values.
Characters are appended to elements and attributes as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more).
Elements names ending in "…" (such as <element.../> or <element...>) indicate that elements/attributes irrelevant to the context are omitted.
A bolded font signifies the item’s first introduction in the document, or an item of particular interest in an example.
is a placeholder for elements from some "other" namespace (like ##other in XSD).
The XML namespace prefixes (defined above) are used to indicate the namespace of the element being defined.
Examples starting with <?xml conform to this specification; others examples are fragments and require additional information to be specified in order to conform to this specification.

2. Definitions

The following section defines the entities of the IXF Data Model. These entities are defined in a manner that is independent from the specific XML syntax used to represent them.

The syntax is defined in section ‎3, Syntax.

2.1 Attribute Definition

An IXF Attribute is a strongly-typed named value. Attributes are the building blocks of Classes and Class Behaviors.

The type of an attribute is specified with the attribute definition, as part of a Class or a Class Behavior definition, while its value is specified when it is used in an Object.

An IXF Attribute definition contains the following elements:

· Name

· Datatype

· Datatype Restriction

· Primary Attribute Indication

· Default Value

· Required Attribute Indication

· Null Allowed Indication

Name must be a valid NCName, as defined in Namespaces in XML.

The attribute Datatypes supported by IXF are a subset of the W3C Schema Language Datatypes, defined in [XSD2]. See section ‎2.10, Attribute Data Types for a complete list.

Datatype Restrictions can be one of the following:

string attribute: Maximum length limit
ixf:objectReference (IDREF) attribute:

Specific IXF Class
Specific IXF Class or descendants
Any IXF Class that supports a specific IXF Class Behavior

The first two ixf:objectReference restrictions are applicable only for Class Attributes; they may not be used with a Class Behavior attribute.

Primary Attribute Indication is applicable only for IXF Class Attributes.

Default Value is used if an IXF Object of the class that defined the attribute does not specify the value of the attribute.

Setting the Required Attribute Indication to Yes indicates that the attribute value must be specified by an IXF Object that includes this attribute.

Null Allowed Indication indicates if the attribute’s value may be set to Null.

IXF Attributes are similar to class member variables in conventional object-oriented programming languages such as Java^TM, or fields in a relational database table.

For syntax, see section ‎3.3, Attribute Syntax.

2.2 Must-Understand Indication Definition

The Must Understand Indication can be used to indicate whether an understanding of the IXF Data Model element that it describes (Class Behavior or InfoItem Extendibility Element) is required for an application to process the IXF Instance Document. The value of Must Understand is either “yes” or “no”. Additional values that refine this may be defined in a future version of this specification.

If an element is tagged with a Must Understand indication with a value other than “no”, the processing application either must obey the semantics (as conveyed by the Class Behavior or InfoItem Extendibility Element URI) and process correctly according to those semantics, or MUST fail processing the IXF Instance Document.

The Must Understand indication allows for robust evolution. Elements tagged with the Must Understand indication with a value other than “no” MUST be presumed to somehow modify the semantics of the IXF Instance Document. Tagging elements in this manner assures that this change in semantics will not be silently (and, presumably, erroneously) ignored by those who may not fully understand it.

For syntax, see section ‎3.5, Class Syntax, and section ‎3.7, InfoItem Syntax.

2.3 Class Behavior Definition

An IXF Class Behavior is a uniquely named collection of zero or more attributes, which is associated with a specific semantics.

Class Behaviors are used to tag a specific Class as having certain semantics and optionally specify behavior-specific attributes.

An IXF Class Behavior definition contains the following elements:

· Name

· Class Behavior Attributes

Class Behaviors are named using URI reference, which uniquely identifies the Class Behavior. The Class Behavior name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). These requirements are identical to the requirements from the value of XML Namespace declaration attributes, as defined in Namespaces in XML.

Class Behavior Attributes collection contains zero or more IXF Attribute definitions. Each Class Behavior attribute name must be unique within the collection of the Class Behavior attributes.

Once published, the definition of Class Behavior must not change. This is because applications may embed assumptions about the semantics or the attributes associated with a Class Behavior into code or persistent storage. Changing the definition of the Class Behavior will break these applications.

Adding, removing or modifying attributes, or changing the semantics of a Class Behavior, must be accomplished by publishing a new Class Behavior with its own unique name.

Unlike Classes, Class Behaviors cannot be instantiated directly in the IXF Instance Document; they must first be applied to a Class. The class behavior attribute values are specified as part of the instance (object) of the relevant class.

The role of Class Behaviors in IXF is similar to the role of interfaces in IDL, COM or the Java^TM language.

For syntax, see section ‎3.4, Class Behavior Syntax, and section ‎3.5, Class Syntax.

2.4 Class Definition

An IXF Class is an entity with the following elements:

· Name

· Parent Class

· Current Class Attributes

· Current Class Behaviors

· Abstract Indication

Name must be a valid QName, as defined in [XMLNS] Namespaces in XML, Section 3: Qualified Names. The class name must be unique within the collection of classes defined in a specific schema.

Current Class Attributes element is a collection of zero or more IXF Attribute definitions.

Current Class Behaviors element is a collection of zero or more IXF Class Behaviors.

Abstract Indication controls whether a class may be instantiated or not.

2.4.1 Parent Class

IXF Classes follow the single inheritance model. The ixf:root class (defined in the IXF Core Schema document) is the ultimate ancestor of all IXF Classes. Multiple inheritance is not supported in the IXF model; however, the same functionality can be achieved using Class Behaviors.

2.4.2 Class Behaviors

The set of Class Behaviors that a class supports is the union of the Current Class Behaviors with the set of Class Behaviors that the Class ancestor supports, that is, Classes inherit Class Behaviors from their ancestors.

The set of Class Behaviors that a class supports is referred to as the Class Behaviors.

It is important to note that when several Class Behaviors are supported by a single Class, more than one attribute with the same name can be defined. Each such attribute definition is scoped within its own Class Behaviors definition. The same is true for attributes which are defined directly in the Class.

A Class Behavior may be marked as Must Understand for a specific class; such indication follows the definition in section ‎2.2, Must Understand Indication Definition.

2.4.3 Class Attributes

The set of attributes available to instances of a specific class is a union of:

The Current Class Attributes
The attributes defined by the Current Class Behaviors
The set of attributes inherited from the class ancestor.

This set of attributes is referred to as the Class Attributes.

2.4.4 Class Primary Attributes

The Class Attributes set may include zero or more attributes marked as Primary Attributes. An IXF Object may not have the same set of values for its Primary Attributes as another object in the same IXF Instance Document, if the other object is an instance of the same class or an instance of a direct or indirect descendant of the object’s class.

This requirement guarantees that the Primary Attributes of an object may be used to uniquely identify it throughout an IXF Instance Document in a similar manner to the Primary Keys of a relational database table.

For syntax, see ‎3.5, Class Syntax.

2.5 Domain Behavior Definition

A Domain Behavior is used to identify an IXF Schema as having a certain well-known semantic meaning, as well as to define which classes in the IXF Schema fill a certain role.

The definition of a Domain Behavior contains the following elements:

· Name

· Named Roles

· Required Class Behaviors (Per Role)

Domain Behaviors are named using URI reference, which uniquely identifies the Domain Behavior. The Domain Behavior name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). These requirements are identical to the requirements from the value of XML Namespace declaration attributes, as defined in Namespaces in XML.

Each Role name in the Named Roles collection must be unique within the collection.

By associating an IXF Schema with an IXF Domain Behavior, the following is implied:

The IXF Schema can be used in contexts that require the semantic implied by the Domain Behavior.
The IXF Schema defines classes that fill the roles defined by the Domain Behavior.

A Class can fulfill a role defined in a Domain Behavior if and only if it supports each of the Required Class Behaviors required by the role.

Domain Behaviors are useful to indicate that a Schema is compatible with or supports a certain use, and to indicate Classes with special roles in the Schema.

For syntax, see section ‎3.6, Domain Behavior Syntax.

2.6 InfoItem Definition

The IXF InfoItem mechanism allows applications to store application-specific or domain-specific information in the IXF Schema or in the IXF Instance Document.

The definition of an InfoItem element contains the following elements:

· Name

· Must Understand Indication

· Datatype

· Content

The IXF InfoItem mechanism is identical to the SOAP Header mechanism, as defined in the [SOAP], Section 4.2: “SOAP Header”. Each InfoItem corresponds to a SOAP Header entry.

An InfoItem name must be a valid QName, as defined in Namespaces in XML, Section 3: Qualified Names.

Must Understand Indication follows the description in Section 11, Must Understand Indication.

Content is strongly typed in the same manner as Attribute. Unlike Attributes, the InfoItem Datatype is specified together with its Content.

For syntax, see section ‎3.7, InfoItem Syntax.

2.7 Schema Definition

An IXF Schema describes the structure and the semantics of a data model.

The description contains the following elements:

· URI

· Location

· Set of Classes

· Set of Class Behaviors

· Set of Domain Behaviors

· Mapping of Domain Behavior Roles to Classes

· InfoItem elements

Schemas are named using URI reference, which uniquely identifies the Schema. The Schema name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). These requirements are identical to the requirements from the value of XML Namespace declaration attributes, as defined in Namespaces in XML.

The Schema Location indicates the location of the Schema document, as a URL.

For additional information on Mapping of Domain Behavior Roles to Classes, see section ‎2.5, Domain Behavior Definition.

Once published, the definition of Schema must not change. This is because applications may embed assumptions about the semantics or the attributes associated with a Schema into code or persistent storage. Changing the definition of the Schema will break these applications.

If the Schema contains items tagged with a Must Understand indication, IXF Instance Documents that reference the Schema must respect this indication in the manner described in section ‎2.2, Must Understand Indication.

For syntax, see section ‎3.2, Schema Document Syntax.

2.8 Object Definition

An IXF Object is an instance of an IXF Class.

Each IXF Object contains the following elements:

· Reference to the Object’s IXF Class

· Object ID

· Collection of IXF Attribute values

2.8.1 Object Class

IXF Objects are instances of IXF Classes. As such, each IXF Object indicates the IXF Class that it is an instance of.

2.8.2 Object ID

Each IXF Object is associated with an Object ID, which uniquely identifies the object within the IXF Instance Document.

The Object ID value must follow the rules defined for the ID Datatype in XML Schema Part 2: Datatypes, Section 3.3.8: ID.

2.8.3 Attribute Values

The IXF Object must specify a value for each attribute in the Class Attributes set that is marked as required. The IXF Object may specify a value for all non-required attributes in the Class Attributes set as well. An IXF Object may not specify a value for an attribute that is not part of the object’s Class Attributes.

For syntax, see section ‎3.9, Object Syntax.

2.9 Instance Document Definition

An IXF Instance Document is a collection of IXF Objects that conform to a specific IXF Schema. An IXF Instance Document contains the following elements:

· Reference to an IXF Schema

· Collection of IXF Objects

Each of the IXF Objects in the IXF Instance Document must be an instance of an IXF Class described in the associated IXF Schema.

For syntax, see section ‎3.8, Instance Document Syntax.

2.10 Attribute Data Types

IXF supports most of the datatypes defined in the “XML Schema Part 2: Datatypes” specification. Some datatypes cannot be fully supported, or cannot be supported at all, because values of the type cannot be represented reliably in common programming languages, or because their usage does not make sense in IXF documents.

The following table details the support for each XSD Datatype:

XSD Datatype	Supported	Comment
string	Yes	Values must be escaped
boolean	Yes
float	Yes
double	Yes
decimal	No	Common programming languages do not support arbitrary precision decimal numbers.
timeDuration	Partially	Lose of precision may occur; Year and Month component cannot be supported.
recurringDuration	No	Cannot be represented by any of the intrinsic types in common programming languages.
binary	Yes	Both Base64 and hex encoding are supported.
anyURI	Yes
ID	No	Not useful in the context of IXF. Note however that this type is used elsewhere in the IXF format to represent object identifiers and other unique identifiers.
IDREF	No	Not useful in the context of IXF. Note however that this type is used elsewhere in the IXF format to represent references between objects.
ENTITY	No	Not useful in the context of IXF
NOTATION	No	Not useful in the context of IXF
QName	No	Not useful in the context of IXF
language	Yes
IDREFS	No	See IDREF.
ENTITIES	No	Not useful in the context of IXF
NMTOKEN	No	Not useful in the context of IXF
NMTOKENS	No	Not useful in the context of IXF
Name	No	Not useful in the context of IXF
NCName	No	Not useful in the context of IXF
integer	No	Common programming languages do not support integer numbers of arbitrary size.
nonPositiveInteger	No	Common programming languages do not support integer numbers of arbitrary size.
negativeInteger	No	Common programming languages do not support integer numbers of arbitrary size.
long	No	Many programming languages do not support integer values that exceed the range of a 32-bit signed integer.
int	Yes
short	Yes
byte	Yes
nonNegativeInteger	No	Common programming languages do not support integer numbers of arbitrary size.
unsignedLong	No	Many programming languages do not support integer values that exceed the range of a 32-bit signed integer.
unsignedInt	No	Many programming languages do not support integer values that exceed the range of a 32-bit signed integer.
unsignedShort	Yes
unsignedByte	Yes
positiveInteger	No	Common programming languages do not support integer numbers of arbitrary size.
dateTime	Yes
time	Yes
timePeriod	No	Cannot be represented by any of the intrinsic types in common programming languages.
date	Yes
month	Yes
year	Yes
century	Yes
recurringDate	No	Cannot be represented by any of the intrinsic types in common programming languages.
recurringDay	No	Cannot be represented by any of the intrinsic types in common programming languages.

The following non-XSD Datatypes are defined in the IXF Core Schema in the IXF namespace and may be used as an IXF Attribute Datatype:

Type	Semantics
xml	XML Fragment; attribute of type ixf:xml allows any well-formed XML from any namespace to be in it's content model.
objectReference	Derived from IDREF, this type is used to define references between IXF Objects.

3. Syntax

3.1 Syntax Overview

The following section describes the representation of IXF Data using XML.

3.2 Schema Document Syntax

An IXF Schema Document is a standard, valid W3C Schema Document as defined in [XSD1], and can be processed by any tool or application that conforms to the W3C Schema Language specifications.

The IXF Schema Document syntax extends the W3C Schema Language with a small number of new attributes and elements. A valid W3C Schema Document that does not contain any of these IXF-specific extensions is still considered to be a valid IXF Schema Document.

3.2.1 The ixf:dataModelRole Attribute

The ixf:dataModelRole applies to a Schema element (xsd:element, xsd:complexType) and indicates that the element represents one of the IXF Data Model entities. The following table summarizes the use of the ixf:dataModelRole attribute:

Value	Applied to	Meaning
ixf:class	xsd:complexType	IXF Class
ixf:attribute	xsd:element	Attribute of an IXF Class or an IXF Class Behavior
ixf:class_behavior	xsd:complexType	IXF Class Behavior

3.2.2 Existing Schemas

IXF elements may appear directly in the Schema document or in any Schema document reference directly or indirectly using the <xsd:import> element.

The standard IXF elements are defined in a specific XSD Schema that may be used by an IXF Schema document. The location of this XSD Schema is:

http://www.ixfstd.org/std/schema/core/1.0/core.xsd

All the elements defined in this schema are associated with the following namespace:

http://www.ixfstd.org/std/ns/core/1.0

3.2.3 Sample IXF Schema Document

The following XML document demonstrates an IXF Schema Document:

<?xml version='1.0' encoding='UTF-8'?>

<schema xmlns="http://www.w3.org/2001/XMLSchema"
   targetNamespace="urn:uuid:F2897562-C289-4320-ACD8-86EF60C4AAD6"
   xmlns:ids="urn:uuid:F2897562-C289-4320-ACD8-86EF60C4AAD6"
   xmlns:ixf="http://www.ixfstd.org/std/ns/core/1.0"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.ixfstd.org/std/ns/core/1.0"
     schemaLocation=
     ”http://www.ixfstd.org/std/schema/core/1.0/core.xsd”/>

<complexType name="Class1" ixf:dataModelRole="ixf:class">
    <complexContent>
      <extension base="ixf:root">
        <sequence>

          <element name="Attribute1" minOccurs="0" nillable="true"
             type="string" ixf:primary="true"
             ixf:dataModelRole="ixf:attribute"/>

          <element name="Attribute2" nillable="true" type="int"
             ixf:dataModelRole="ixf:attribute"/>

          <element name="Attribute3" minOccurs="0" nillable="true"
             type="string" ixf:dataModelRole="ixf:attribute"/>

        </sequence>
      </extension>
    </complexContent>
</complexType>

<complexType name="Class2" ixf:dataModelRole="ixf:class">
    <complexContent>
      <extension base="tns:Class1">
        <sequence>

          <element name="Attribute4" minOccurs="0" nillable="true"
             type="boolean" ixf:primary="true"
             ixf:dataModelRole="ixf:attribute"/>

          <element name="Attribute5" nillable="true"
             type="timeDuration"
             ixf:dataModelRole="ixf:attribute"/>

          <element name="Attribute6" minOccurs="0" nillable="true"
             type="string" ixf:dataModelRole="ixf:attribute"/>

        </sequence>
      </extension>
    </complexContent>
</complexType>

<element name=”Envelope” type="soap:Envelope"/>

</schema>

3.3 Attribute Syntax

An IXF Attribute (of an IXF Class or an IXF Class Behavior) is represented using the xsd:element element, marked with a ixf:dataModelRole="ixf:attribute” attribute:

...

...

The IXF Attribute definition appears as part of the IXF Class definition or the IXF Class Behavior definition in the following manner:

· The xsd:complexType element which represents the IXF Class or the IXF Class Behavior must have a single xsd:sequence as immediate child element.

· The xsd:sequence element must have zero or more xsd:element as immediate child elements, marked with a ixf:dataModelRole=”ixf:attribute”. Each of these xsd:element elements represent an IXF Attribute associated with the IXF Class or the IXF Class Behavior.

· The order of the IXF Attributes matches the order defined using the xsd:sequence elements.

Syntax:

...

<element name="NCName" ...
ixf:dataModelRole="ixf:attribute"/>*

</sequence...>

</complexType...>

...

<element name="NCName" ...
ixf:dataModelRole="ixf:attribute "/>*

</sequence...>

</complexType...>

The xsd:element element which describes the IXF attribute must have a xsd:maxOccurs attribute with a value of 1 (one).

If the IXF Attribute is Required, the value of the xsd:minOccurs attribute must be 1 (one), otherwise it must be 0 (zero):

<element name="NCName" minOccurs="0|1"? maxOccurs=1? ... />*

If the IXF Attribute is part of the Class Primary Attributes collection, the ixf:primary attribute must have a value of true. Otherwise, the attribute must have a value of false.

      <element name="NCName" ...
         ixf:dataModelRole="ixf:attribute"
         ixf:primary=”boolean”/>*

The ixf:primary attribute is not relevant and must not be present in a definition of a Class Behavior Attribute.

The attribute Datatype, as indicated by the value of the type attribute, must be one of the supported types listed in Attribute Data Types.

Maximum length restriction on a string attribute must be indicated in the following manner:

<simpleType>

<restriction base="string">

<maxLength value="int"/>

</restriction>

</simpleType>

</element>

Reference restriction on an IDREF (ObjectReference) attribute must be indicated in the following manner:

ixf:restrictionClassName must be specified if and only if the value of ixf:restrictionType is Class or ClassAndDescendants.

ixf:restrictionBehaviorURI must be specified if and only if the value of ixf:restrictionType is Behavior.

The following are some examples of IXF Attributes syntax:

</restriction>

</simpleType>

</element>

</sequence>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

3.4 Class Behavior Syntax

An IXF Class Behavior definition is represented using a xsd:complexType element, marked with a ixf:dataModelRole="ixf:class_behavior” attribute. The Class Behavior name is the concatenation of the value of xsd:complexType element name attribute and the Schema targetNamespace in the following manner:

targetNamespace#behavior-name

For each such xsd:complexType element, there must be a corresponding xsd:element element whose name attribute value corresponds to the name attribute value of the xsd:complexType element, and whose type attribute value points to the xsd:complexType.

...

</complexType>

<element name="NCName" type="QName"/>

For example:

...

</complexType>

3.5 Class Syntax

An IXF Class is represented using a xsd:complexType element, marked with a ixf:dataModelRole="ixf:class” attribute. The Class Behavior name is represented using the value of xsd:complexType element name attribute.

A specific class defined in a specific schema can be referenced externally using a single URI, composed using a concatenation of the Schema targetNamespace and the class name in the following manner:

targetNamespace#class-name

...

</complexType>

<element name="NCName" type="QName"/>

For example:

...

</complexType>

<element name="class1" type="tns:class1"/>

The xsd:complexType element content must contain the following XML syntax, conforming to the W3C Schema specification:

<complexContent>

<extension base="NCName">

<sequence>

<element.../>*

</sequence>

</extension>

</complexContent>

</complexType>

The Current Class Attributes are represented in the manner described in Section 10, IXF Attribute.

Class Behaviors which are supported by the Class are represented using an xsd:element with a ref attribute which references the xsd:complexType defined for the Class Behavior in the Class Behavior schema. If the Class Behavior understanding is required for this class, an ixf:mustUnderstand attribute with a value of “yes” must be specified.

The fact that a class is abstract is represented by tagging the xsd:complexType element with an xsd:abstract attribute, with a value of “true”.

The following is the complete representation of a Class:

<element.../>*

<element ref=”QName" ixf:mustUnderstand=”string”.../>*

</sequence>

</extension>

</complexContent>

</complexType>

3.6 Domain Behavior Syntax

IXF Domain Behaviors are defined on a global scope and not in the scope of a specific schema. Therefore, a formal definition of a Domain Behavior should logically be stored separately from any schema. An XML format for a Domain Behavior definition does not exist as of today. However, it is expected that future versions of this specification will define such a format.

The mapping of Domain Behavior Roles to specific classes is defined in the Schema document in the following manner:

...

<ixf:domainBehaviors>

<ixf:behavior ixf:uri="anyURI">*

<ixf:role ixf:name="string" ixf:class="QName"/>*

</ixf:behavior>

</ixf:domainBehaviors>

</appinfo>

</annotation>

...

3.7 InfoItem Syntax

The IXF InfoItem syntax is derived from the SOAP Header mechanism, as defined [SOAP], Section 4.2: “SOAP Header”, with the following difference:

SOAP Header entries always appear as immediate child elements of the Header element. The IXF Instance Document conforms to the SOAP Envelope syntax; therefore IXF InfoItems, which apply to the IXF Instance Document as a whole, are stored as SOAP Header entries. However, IXF InfoItems may also appear in the IXF Schema Document.

Like any SOAP Header entry, IXF InfoItems are identified using the QName of the entry element.

InfoItems are specified in the Instance Document in the following manner:

<soap:Envelope ...>

<soap:Header ...>

*

</soap:Header>

<soap:Body>

...

</soap:Body>

</soap:Envelope>

In the Schema Document the InfoItems are stored inside an annotation\appinfo element:

<schema...>

<soap:Header...>

*

</soap:Header>

</annotation>

...

</schema>

If an InfoItem, either in the IXF Instance Document or in the IXF Schema Document, is tagged with an ixf:mustUnderstand with a value other than “no”, the IXF Instance Document SOAP Header must contain a ixf:containsMustUnderstand SOAP Header entry with an soap:mustUnderstand=”1” attribute:

<soap:Envelope ...>

<soap:Header ...>

<ixf:containsMustUnderstand soap:mustUnderstand=”1”/>

</soap:Header>

<soap:Body>

...

</soap:Body>

</soap:Envelope>

3.8 Instance Document Syntax

An IXF Instance Document is represented as a SOAP Message, as defined in the [SOAP]. Applications that process IXF Instance Documents must conform to the SOAP specification in addition to conforming to this specification.

An IXF Instance Document must also meet the following conditions:

· It must be associated with an IXF Schema Document.

· Both the soap:Body element and the soap:Header elements must be encoded using the http://schemas.xmlsoap.org/soap/encoding/ encoding style.

The soap:Header element contains the IXF InfoItems elements as well as other non-IXF SOAP Header entries.

3.9 Object Syntax

IXF Objects are encoded using the SOAP Encoding Rules, as defined in [SOAP], Section 5 “SOAP Encoding”, as SOAP multi-reference Compound Values. In accordance with the SOAP specification, references between objects are encoded as accessors to multi-referenced values.

The SOAP Body may include other values, which do not represent IXF Objects. However, IXF Objects may only reference other IXF Objects.

Attributes are encoded as described in section ‎3.3, Attribute Syntax.

Class Behavior Attributes are encoded as nested Compound Values, with the Class Behavior Name as the qualified accessor name:

<soap:Envelope ...>

<soap:Header ...>?

</soap:Header>

<soap:Body>?

<ixf:object xsi:type=”QName” id=”ID”>*

<QName.../>*

<QName>*

<QName.../>*

</QName>

</ixf:object>

...

</soap:Body>

</soap:Envelope>

For example:

<soap:Envelope ...>

<soap:Header ...>?

</soap:Header>

<soap:Body>?

<ixf:object xsi:type=”Class1” id=”Id1”>*

<ns1:attribut1>some value</ns1:attribute1>

<ns1:attribut2>some value</ns1:attribute2>

<ns1:attribut3 href=”#Id2”/>

...

<ns2:behavior1>

<ns2:attribut3>some value</ns2:attribute3>

<ns2:attribut4>some value</ns2:attribute4>

</ns2:behavior1>

<ns3:behavior2>

<ns2:attribut5>some value</ns2:attribute5>

<ns2:attribut6>some value</ns2:attribute6>

</ns3:behavior2>

</ixf:object>

...

</soap:Body>

</soap:Envelope>

4. Standard Behaviors

The following section describes the Standard Behaviors, designed to define the semantics and representation of common idioms relevant to the intended usage of the IXF format. It is expected that additional standard behaviors will be defined in future versions of this specification.

Processing applications are not required to understand and use these Standard Behaviors, unless they are defined with a Must Understand indication with a value other than “no”. However, it is strongly recommended that where a Standard Behavior exists which provides the required semantics, it will be used in preference to defining a new behavior, as doing so will increase interoperability.

In the following section a shorthand form for the behaviors URIs is used, in order to improve readability:

· The text <ixfstdns-c> should be replaced with http://www.ixfstd.org/std/ns/core/classBehaviors.

· The text <ixfstdns-d> should be replaced with http://www.ixfstd.org/std/ns/core/domainBehaviors.

For example, the following URI:
http://www.ixfstd.org/std/ns/core/classBehaviors/timeStamp/1.0
is written as <ixfstdns-c>/timeStamp/1.0; the following URI:
http://www.ixfstd.org/std/ns/core/domainBehaviors/changeTracking/1.0
is written as <ixfstdns-d>/changeTracking/1.0.

Some Standard Behaviors require the presence of other behaviors. Such requirements are listed in the Prerequisites section of each behavior listed below.

4.1 Time Stamping

Time Stamping support provides the ability to time-stamp IXF Objects.

4.1.1 Class Behaviors

The Time Stamping Class Behaviors schema file located at
http://www.ixfstd.org/std/schema/classBehaviors/timeStamp.xsd.

4.1.1.1 “Time Stamping” Class Behavior

URI	<ixfstdns-c>/timeStamp/1.0#timeStamp
Description	Provides the object’s Creation Time and Modification Time.
Prerequisites	None.

Attributes:

Name	Type	Optional	Nillable	Default Value
creationTime	xsd:dateTime	Y	Y	N/A
modificationTime	xsd:dateTime	Y	Y	N/A

4.1.2 Domain Behaviors

None

4.2 Change Tracking

Change Tracking support provides a standard mechanism for tracking changes in an IXF Instance Document.

Change Tracking is toggled on or off on a per-class basis. Changes are tracked only for instances of classes marked as requiring this functionality using the appropriate behavior (defined later in this section). Such classes are referred to as Tracked Classes, and instances of these classes are referred to as Tracked Instances.

Changes on tracked instances are documented using instances of the Change class. A group of consecutive changes MAY be grouped together using Change Transactions, to express a relationship between a set of changes. Change Transactions may be nested within other Change Transactions.

Each Change instance represents a discrete operation on a tracked instance. The following table describes the set of operations tracked:

Table 1Change Tracking Operations

Operation	Description
Object Value Modified	The value of one or more of the object attributes is modified.
Object Deleted	The object is deleted.
Object Created	A new instance is created.

The following relationships exist between changes and other changes, changes and transactions and transactions and other transactions:

· A timeline describing the order in which changes were applied to the IXF Instance Document as a whole.

· A timeline describing the order in which changes were applied to a specific IXF object.

Changes are logically tracked from a certain baseline. The definition of the baseline is application specific. Once the baseline is established, the following axioms hold:

· The set of IXF Objects in the IXF Instance Document represent the current state at any given point in time

· If the changes described using the change-related objects are applied to the Tracked Instances in reverse order, the state of the Tracked Instances will be the same as it was when the baseline was established.

Note that in order for these axioms to hold true, all the objects that are referred to using ixf:objectReference attributes of Tracked Instances must also be Tracked Instances.

4.2.1 Class Behaviors

The Change Tracking Class Behaviors schema file located at
http://www.ixfstd.org/std/schema/classBehaviors/changeTracking.xsd.

4.2.1.1 “Transaction” Class Behavior

URI

<ixfstdns-c>/changeTracking/1.0#transaction

Description

Groups of a set of consecutive changes to express a relationship between them.

Prerequisites

IXF Schemas which use this behavior must also use the following Domain Behavior:

<ixfstdns>/domainBehaviors/changeTracking/1.0

Attributes:

Name

Type

Optional

Nillable

Default Value

ixf:objectReference

See Restriction #1

N/A

parent

ixf:objectReference

See Restriction #2

N/A

· Restriction #1: Restricted to behavior =
<ixfstdns-c>/changeTracking/1.0#transaction

· Restriction #2: Restricted to behavior =
<ixfstdns-c>/changeTracking/1.0#transaction

4.2.1.2 “Change” Class Behavior

URI

<ixfstdns-c>/changeTracking/1.0#change

Description

Describes the properties common to all change types.

Prerequisites

Classes which support this behavior must also support one and only one of the following behaviors:

· <ixfstdns-c>/changeTracking/1.0#objectDeleted

· <ixfstdns-c>/changeTracking/1.0#objectCreated

· <ixfstdns-c>/changeTracking/1.0#objectValueModified

IXF Schemas which use this behavior must also use the following Domain Behavior:

· <ixfstdns>/domainBehaviors/changeTracking/1.0

Attributes:

Name	Type	Optional	Nillable	Default Value
transaction	ixf:objectReference See Restriction #1	N	N	N/A
previous	ixf:objectReference See Restriction #2	N	Y	N/A
previousPerObject	ixf:objectReference See Restriction #3	N	Y	N/A

· Restriction #1: Restricted to behavior =
<ixfstdns-c>/changeTracking/1.0#transaction

· Restriction #2: Restricted to behavior =
<ixfstdns-c>/changeTracking/1.0#change

· Restriction #3: Restricted to behavior =
<ixfstdns-c>/changeTracking/1.0#change

4.2.1.3 “Object Deleted” Change Class Behavior

URI

<ixfstdns-c>/changeTracking/1.0#objectDeleted

Description

Stores the information about a deleted object.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixfstdns-c>/changeTracking/1.0#change

Attributes:

Name	Type	Optional	Nillable	Default Value
objectId	xsd:string	N	N	N/A
objectType	xsd:string	N	N	N/A
objectAttributes	ixf:xml	N	N	N/A

The objectId and the objectType attributes store the Object ID and the Class Name of the deleted object, respectively.

Note that the objectId is stored as a string, and not as ixf:objectReference, because the object is no longer part of the IXF objects set. In fact, the Object ID of the deleted object may be reused to identify other objects.

The objectAttributes attribute stores an XML representation of the deleted object attributes. The XML element stored in the objectAttributes attribute must conform to the schema of the XML element that corresponds to the IXF Class pointed to by objectType. Meaning, the XML element content must be identical to the content of the ixf:object element of the deleted object.

4.2.1.4 “Object Created” Change Class Behavior

URI

<ixfstdns-c>/changeTracking/1.0#objectCreated

Description

Stores the information about a newly created object.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixfstdns-c>/changeTracking/1.0#change

Attributes:

Name	Type	Optional	Nillable	Default Value
createdObject	ixf:objectReference	N	N	N/A

4.2.1.5 “Object Value Modified” Change Class Behavior

URI

<ixfstdns-c>/changeTracking/1.0#objectValueModified

Description

Stores the information about modified object attributes.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixfstdns-c>/changeTracking/1.0#change

Attributes:

Name	Type	Optional	Nillable	Default Value
modifiedObject	ixf:objectReference	N	N	N/A
ObjectType	ixf:xml	N	N	N/A
OldValues	ixf:xml	N	N	N/A

The modifiedObject attribute references the modified object.

The oldValues attribute contains the values of the modified attributes as they were before the modification.

The XML element stored in the oldValues attribute must conform to the schema of the XML element that corresponds to the schema of a hypothetical class, one that would be derived from the same IXF Class pointed to by objectType, but include only the modified attributes.

4.2.1.6 “Track Changes” Class Behavior

URI	<ixfstdns-c>/changeTracking/1.0#trackChanges
Description	Marks an IXF Class as a Tracked Class.
Prerequisites	None

Attributes: None

Tagging a class with this behavior marks it as a Tracked Class.

4.2.2 Domain Behaviors

4.2.2.1 “Change Tracking” Domain Behavior

URI	<ixfstdns>/domainBehaviors/changeTracking/1.0
Description	Identifies the Change Tracking related classes in an IXF Schema.
Prerequisites	None

Roles:

Role	Required Class Behaviors
objectDeleted	<ixfstdns-c>/changeTracking/1.0#change <ixfstdns-c>/changeTracking/change/1.0#objectDeleted
objectValueModified	<ixfstdns-c>/changeTracking/1.0#change <ixfstdns-c>/changeTracking/change/1.0#objectValueModified
objectCreated	<ixfstdns-c>/changeTracking/1.0#change <ixfstdns-c>/changeTracking/change/1.0#objectCreated
transaction	<ixfstdns-c>/changeTracking/1.0#transaction

4.3 File Association

The File Association support provides a standard mechanism for associating IXF Objects with files.

The mechanism provides the following functionality:

· Associating an IXF Object with a specific file

· Describing the properties of a file:

o File Name

o Physical Location

o MIME Content Type

· Describing secondary files: files that are required only because the referenced file is referencing them.

A single file may be referenced by zero or more IXF Objects in the same IXF Instance Document.

Secondary files are files that are not referenced by any IXF Object in the IXF Instance Document, but are still needed for technical reasons, such as the peculiarities of a file format.

Some examples of secondary files:

· HTML Document may require that the resources it references, such as image files or style sheets, are also described, so that the HTML Document and the resources associated with it can be manipulated together.

· Multiple TIFF files representing the pages of a single scanned document.

· Multi-sheet CAD files.

4.3.1 Class Behaviors

The File Association Class Behaviors schema file located at
http://www.ixfstd.org/std/schema/classBehaviors/files.xsd.

4.3.1.1 “File Association” Class Behavior

URI	<ixfstdns-c>/files/1.0#fileAssociation
Description	Indicates that instances of this class may be associated with a file document.
Prerequisites	None.

Attributes:

Name

Type

Optional

Nillable

Default Value

file

ixf:objectReference

See Restriction #1

N/A

· Restriction #1: Restricted to behavior = <ixfstdns-c>/files/1.0#mainFile

4.3.1.2 “File Description” Class Behavior

URI

<ixfstdns-c>/files/1.0#fileDescription

Description

Indicates that instances of this class describe files that may be referenced by objects in this IXF Instance Document.

Prerequisites

Classes which support this behavior must also support one and only one of the following Class Behaviors:

· <ixfstdns-c>/files/1.0#mainFile

· <ixfstdns-c>/files/1.0#secondaryFile

IXF Schemas which use this behavior must also use the following Domain Behavior:

· <ixfstdns-d>/domainBehaviors/files/1.0

It is recommended that classes which supports this behavior will also support the following behavior:

· <ixfstdns-c>/timeStamp/1.0#timeStamp

Attributes:

Name	Type	Optional	Nillable	Default Value
filename	xsd:string	N	N	N/A
contentType	xsd:string	N	Y	N/A
location	xsd:anyURI	N	N	N/A
computerName	xsd:string	Y	Y	N/A

The filename attribute value specifies the name of the file, which may include a relative path component. This name must be used in all contexts that require a file name. The value of the location attribute should be used only for the purpose of retrieving the physical file.

If the file name contains a relative path component, it should be interpreted as relative to a logical root folder that is shared by all the files described using this Class Behavior. This interpretation must be preserved when files are retrieved from the location indicated by location attribute values and stored at another location.

For example, the value of the filename attribute may be Docs\2001\Revenues.txt, while the value of the location attribute may be http://example.com/cgi-bin/retrieveFile?fileid=32887834, and we may have an application that scans an IXF Instance Document and saves all the files referenced in the document to the local file system, with c:\folder1\folder2 as the root folder. In such a case, the file must be saved under the file name c:\folder1\folder2\Docs\2001\Revenues.txt.

Similarly, the value of the contentType attribute must be considered as the actual content type of the referenced file, overriding any content type that may be derived from the location attribute value or from other sources.

4.3.1.3 “Main File” Class Behavior

URI

<ixfstdns-c>/files/1.0#mainFile

Description

Indicates that instances of this class describe files that objects in the IXF Instance Document may be associated with directly.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixfstdns-c>/files/1.0#fileDescription

Attributes: None

4.3.1.4 “Secondary File” Class Behavior

URI

<ixfstdns-c>/files/1.0#secondaryFile

Description

Indicates that instances of this class describe files that exist due to technical reasons and not because an object is directly associated with them.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixfstdns-c>/files/1.0#fileDescription

Attributes:

Name

Type

Optional

Nillable

Default Value

previousSibling

ixf:objectReference

See Restriction #1

N/A

· Restriction #1: Restricted to behavior =
<ixfstdns-c>/files/1.0#fileDescription

Each secondary file must point directly or indirectly using its PreviousSibling attribute to an instance of a main file class.

If physical order between several secondary files associated with a single main file is required, the relationship must be expressed using the PreviousSibling attribute.

4.3.2 Domain Behaviors

4.3.2.1 “Files Domain” Behavior

URI	<ixfstdns-d>/domainBehaviors/files/1.0
Description	Identifies the class which describes the files in the IXF Instance Document.
Prerequisites	None

Roles:

Role	Required Class Behaviors
file	<ixfstdns-c>/files/1.0#fileDescription

4.4 Versioning

The Versioning support provides the ability to tag IXF Objects with versioning information. Several different IXF Objects may in fact represent different revisions of the same master entity.

The versioning information includes the version identifier, as well as the identifier of the previous version of the master entity.

Note that Versioning support is different from Change Tracking support. Versioning support is not directly related to the changes performed on the IXF Instance Document. Instead, it is designed to capture the versioning information described in another system.

For example, if the IXF Instance Document is originated in a Document Management System (DMS), the Versioning support will describe the versions as they are maintained in the DMS, while the Change Tracking support will describe the changes performed on the IXF Instance Document since it was generated from the DMS.

The identity of the master entity is defined by its Primary Attributes. Meaning, given an IXF Object which supports the Versioning Class Behavior, the previous revision of the IXF Object can be located by using its Primary Attributes as defined in the IXF Class, together with the previousVersion attribute.

4.4.1 Class Behaviors

The Versioning Class Behaviors schema file located at
http://www.ixfstd.org/std/schema/classBehaviors/versioning.xsd.

4.4.1.1 “Versioning Class” Behavior

URI	<ixfstdns-c>/versioning/1.0#version
Description	Describes the object’s version information.
Prerequisites	None.

Attributes:

Name	Type	Optional	Nillable	Default Value
version	xsd:string	N	Y	N/A
previousVersion	xsd:string	N	Y	N/A

4.4.2 Domain Behaviors

None

4.5 Links

The link-related standard behaviors are designed to formalize and classify the relationships between objects in an IXF Instance Document.

4.5.1 Class Behaviors

The Links Class Behaviors schema file located at
http://www.ixfstd.org/std/schema/classBehaviors/links.xsd.

4.5.1.1 “Link” Class Behavior

URI	<ixfstdns-c>/links/1.0#link
Description	Indicates that instances of this class represent a link between two objects. Without further information, the link should be considered symmetrical.
Prerequisites	None.

Attributes:

Name	Type	Optional	Nillable	Default Value
object1	ixf:objectReference	N	Y	N/A
object2	ixf:objectReference	N	Y	N/A

4.5.1.2 “Directed Link” Class Behavior

URI

<ixfstdns-c>/links/1.0#directedLink

Description

Indicates that the link has a direction, and that the direction is from Object1 to Object2.

Prerequisites

Classes which support this behavior must also support the following behavior:

· <ixdstdns>/classBehaviors/links/1.0#link

Attributes: None

4.5.1.3 “Tree Link” Class Behavior

URI

<ixfstdns-c>/links/1.0#treeLink

Description

Indicates that the data structure implied by this link complies with the standard definition of tree – no loops, each object has only one parent.

Prerequisites

Classes which support this behavior must also support the following behaviors:

· <ixdstdns>/classBehaviors/links/1.0#link

· <ixdstdns>/classBehaviors/links/1.0#directedLink

As implied by the presence of the directedLink behavior, Object1 points to the parent object and Object2 to the child object.

Attributes: None

4.5.1.4 “Hierarchical Link” Class Behavior

URI

<ixfstdns-c>/links/1.0#hierarchicalLink

Description

Indicates that the data structure implied by this link does not have loops. However, unlike the tree data structure, an object may have multiple parents.

Prerequisites

Classes which support this behavior must also support the following behaviors:

· <ixdstdns>/classBehaviors/links/1.0#link

· <ixdstdns>/classBehaviors/links/1.0#directedLink

As implied by the presence of the directedLink behavior, Object1 points to the parent object and Object2 to the child object.

Attributes: None

4.5.2 Domain Behaviors

None

5. Packaging Formats

IXF Instance Documents reference resources such as IXF Schema files and associated files using URIs. At times it is desirable to package the IXF Instance Document, along with some of these resources, into a single document. Such packaging simplifies the transportation and storage of IXF Data.

The specification defines two different packaging formats. Applications are encouraged to support both formats, in addition to supporting non-packaged IXF Instance Documents, which reference resources using standard URLs.

5.1 IXF Archive

IXF Archive files must be implemented in the following manner:

The base file format is ZIP, as described in [ZLIB].
The ZIP may be compressed or uncompressed.
All files must be stored in the root folder of the ZIP file.
The ZIP file may not contain sub-folders.
The IXF Instance Document file must be stored in the archive, and its file name must be IXF_Data.xml.
If the IXF Schema Document is stored in the archive, its file name must be IXF_Schema.xsd.
If additional XSD Schema documents, such as Class Behavior schema documents, are stored in the archive, they must be named according to the file name pattern IXF_*.xsd.
All file names starting with the prefix IXF_ are reserved and must not be used.
Files referenced using the location attribute of the File Description Class Behavior may be stored in the ZIP file under any file name, except for the filenames reserved above.
Additional files may be stored in the archive using any file name, except for the file names reserved above.
References from the IXF Instance Document to files stored in the archive must be relative URIs.

Files stored inside zip file should be treated as if they can be referenced using the following hypothetical URL syntax:

ixfarchive:<IXF Archive File URL>::\filename

The MIME type of an IXF Archive File is application/x-ixfstd-ixfarchive.

5.2 IXF Message Package

IXF data is stored in an IXF Message Package in the following manner:

The IXF Message document must be a valid SOAP Message Package as specified in SOAP Messages with Attachments specification [SOAPWA].
The IXF Instance Document must be the Primary SOAP Message, and as such, must be carried in the root body part of the Multipart/Related structure.
If the IXF Schema Document or any other W3C Schema Document is stored in the message, its MIME Part Content Type must be text/xml.
For files that are stored in the message and referenced using the location attribute of the File Description Class Behavior, the file name specified using the filename attribute of the File Description Class Behavior must be reflected in a Content-Disposition header of the relevant MIME part.

6. Appendix – Mapping iXF Datatypes to Programming Languages Types

The following section describes the rules for mapping IXF Datatypes to common Programming Languages types. Implementation of IXF must adhere to these rules.

6.1 Mapping Datatypes to COM Variant types

The following table describes a one-way mapping between the Datatypes supported by IXF and listed in Attribute Data Types and the COM Variant types.

W3C Datatype	COM Variant Type	Comment
String	VT_BSTR
Boolean	VT_BOOL
Float	VT_R4	IEEE single-precision 32-bit floating point type
Double	VT_R8	IEEE double-precision 64-bit floating point type
timeDuration	VT_R8	Duration represented in seconds; Value = nS + 60 * nM + 3600 * nH + 86400 * nD
binary	VT_ARRAY \| VT_UI1
anyURI	VT_BSTR
language	VT_BSTR
Int	VT_I4	32-bit integer
short	VT_I2	16-bit integer
byte	VT_I1	-128 ... 127
unsignedShort	VT_UI4	0 ... 65535
unsignedByte	VT_UI1	0 ... 255
dateTime	VT_DATE	Time is in UTC
time	VT_DATE	Time is in UTC
date	VT_DATE
month	VT_DATE	Represented as the 1^st day of the specified month.
year	VT_DATE	Represented as the 1^st day of the 1^st month of the specified year.
century	VT_DATE	Represented as the 1^st day of the 1^st month of the 1^st year of the specified century.
ixf:objectReference	VT_BSTR
ixf:xml	VT_DISPATCH	See XML Attributes.

Note that a reverse mapping from a COM Variant value to a string representation of the value in the format described in the XML Schema Part 2: Datatypes document can be implemented given the Datatype explicitly in addition to the actual Variant value.

6.2 Mapping Datatypes to Java types

The following table describes a one-way mapping between the Datatypes supported by IXF and listed in Attribute Data Types and the Java types.

W3C Datatype	Java Type	Comment
string	String
boolean	Boolean
Float	Float	IEEE single-precision 32-bit floating point type
double	Double	IEEE double-precision 64-bit floating point type
timeDuration	Double	Duration represented in seconds; Value = nS + 60 * nM + 3600 * nH + 86400 * nD
binary	Byte[]
anyURI	Java.net.URL
language	String
int	Integer	32-bit integer
short	Short	16-bit integer
byte	Byte	-128 ... 127
unsignedShort	Integer	0 ... 65535
unsignedByte	Short	0 ... 255
dateTime	java.util.Date	Time is in UTC
time	java.util.Date	Time is in UTC
date	java.util.Date
month	java.util.Date	Represented as the 1^st day of the specified month.
year	java.util.Date	Represented as the 1^st day of the 1^st month of the specified year.
century	java.util.Date	Represented as the 1^st day of the 1^st month of the 1^st year of the specified century.
ixf:objectReference	String
ixf:xml	Custom type	See XML Attributes.

Note that a reverse mapping from a Java value to a string representation of the value in the format described in the XML Schema Part 2: Datatypes document can be implemented given the Datatype explicitly in addition to the actual value.

6.3 XML Attributes

XML Attribute Values should be represented as a composite object with two accessors:

XML fragment text
Namespaces Collection

The Namespaces collection must contain an entry for each Namespace prefix that is not defined directly within the XML fragment using the xmlns attribute.

For example, given the following XML fragment:

<ns1:elem1 xmlns:ns2="http://example.com/ns2">

<ns2:elem2>

...

</ns2:elem2>

</ns1:elem1>

There is no need to define ns2, since it is defined directly in the fragment, but ns1 must be defined using the Namespaces collection.

It is important to note that the exact XML fragment text is not preserved, however the XML DOM representation is preserved.

7. Appendix – IXF XSD Schemas

7.1 IXF Core Schema

<xsd:schema targetNamespace="http://www.ixfstd.org/std/ns/core/1.0" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ixf="http://www.ixfstd.org/std/ns/core/1.0">

<xsd:complexType name="objectReference">

<xsd:attribute name="href" type="xsd:IDREF" use="required" />

</xsd:complexType>

<xsd:complexType name="xml">

<xsd:sequence>

<xsd:any />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="root" abstract="true">

<xsd:attribute name="id" type="xsd:ID" use="required" />

</xsd:complexType>

<xsd:element name="object" type="ixf:root" />

<xsd:element name="domainBehaviors">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="behavior" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="role" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:attribute name="name" type="string" />

<xsd:attribute name="class" type="string" />

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="URI" type="anyURI" use="required" />

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:attribute name="dataModelRole">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="class" />

<xsd:enumeration value="attribute" />

<xsd:enumeration value="class_behavior" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:attribute name="restrictionType">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="behavior" />

<xsd:enumeration value="class" />

<xsd:enumeration value="classAndDescendants" />

<xsd:enumeration value="any" />

</xsd:restriction>

</xsd:simpleType>

</xsd:attribute>

<xsd:attribute name="restrictionBehaviorURI" type="xsd:anyURI" />

<xsd:attribute name="restrictionClassName" type="xsd:string" />

<xsd:attribute name="primary" type="xsd:boolean" />

<xsd:attribute name="mustUnderstand" type="xsd:string" />

<xsd:attribute name="containsMustUnderstand" />

</xsd:schema>

7.2 Standard Behavior Schemas

7.2.1 Time Stamping

</sequence>

</complexType>

</schema>

7.2.2 Change Tracking

</sequence>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

</sequence>

</complexType>

</complexType>

</schema>

7.2.3 File Association

</sequence>

</complexType>

</sequence>

</complexType>

</complexType>

</sequence>

</complexType>

</schema>

7.2.4 Versioning

</sequence>

</complexType>

</schema>

7.2.5 Links

</sequence>

</complexType>

</complexType>

</complexType>

</complexType>

</schema>

8. References

[RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997
[SOAP] W3C Note, “Simple Object Access Protocol”
[RFC2387] The MIME Multipart/Related Content-type, RFC 2387
[ZLIB] ZLIB Compressed Data Format Specification version 3.3, RFC 1950
[SOAPWA] W3C Note "SOAP Messages with Attachments"
[XSD1] W3C Recommendation, “XML Schema Part 1: Structures”
[XSD2] W3C Recommendation, “XML Schema Part 2: Datatypes”
[XMLNS] W3C Recommendation Namespaces in XML

[DEFLATE] DEFLATE Compressed Data Format Specification version 1.3, RFC 1951