Documentation for AS.AIF

Table of Contents

top

Schema Document Properties

Target Namespace http://aif.org/draft
Version 0.2
Element and Attribute Namespaces
  • Global element and attribute declarations belong to this schema's target namespace.
  • By default, local element declarations belong to this schema's target namespace.
  • By default, local attribute declarations have no namespace.
Documentation

This schema is a high-level, first-cut implementation of an xml-schema that's within the spirit of the the Argumentation Interchange format as described in the Strawman document (1). AIF is intended to facilitate the transmission of arguments between different end-points, including software agents and argumentation visualization tools.

My original goal in this exercise was to define,

  • a general schema (loosely describing a basic structure for an XML document) and
  • a particular schema that overides the general the schema for a particular implementation.

Thus if I created a particular application that generates AIF then I could demonstrate a schema for that implementation building on some basic principles and any aif generated by that implementation should validate against both schemas.

However, upon closer examination it turns out that the only way to do this is in XML Schema is to add in "extension" nodes into the schema which can then allow multiple "xs:any, namespace:other" children (2). This will work, but to my eye, is not at all elegant, especially after more than one layer of inheritance. So the extensibility mechanism in this design is xs:extension and an example of an extended schema is shown in AS.AIF.xsd that is included in this directory. An extended schema should first include this schema and then use xs:extension to add further attributes and children to context, s-nodes, i-nodes and maybe edges.

Using xs:extension means that an AIFXML message that validates against an extended AIF schema will not validate against this one, but the final XML documents produced will be pretty clean, and this schema gives you a pretty solid foundation to build upon. In particular this schema helps maintain coherence of "links" between edges, i-nodes and s-nodes and restrict list of s-node types to those listed in the context (via the id, from-node and to-node attributes).

Useful resources include
  1. AIF Strawman, version 0.8,
  2. http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html,
  3. http://www.xfront.com/BestPracticesHomepage.html,
  4. http://www.w3schools.com/schema/default.asp.

Declared Namespaces

Prefix Namespace
xml http://www.w3.org/XML/1998/namespace
xs http://www.w3.org/2001/XMLSchema
aif http://aif.org/draft
xhtml http://www.w3.org/1999/xhtml
Schema Component Representation
<xs:schema elementFormDefault="qualified" targetNamespace="http://aif.org/draft" version="0.2">
...
</xs:schema>
top

Global Declarations

Element: aif

Name aif
Type Locally-defined complex type
Nillable no
Abstract no
Documentation

This schema uses the "venetian blind" design pattern and so only exposes this top-level element.

Key and Keyref constraints are implemented to ensure that

  • s-types have unique names and s-nodes can only refer to named types
  • s and i nodes have unique id's
  • edges refer to existing s and i nodes
However there is no constraint to say that i-nodes cannot be connected to i-nodes.

Logical Diagram
XML Instance Representation
<aif:aif>
<!--
Key Constraint - s-typeKey
Selector - ./aif:context/aif:s-types/aif:s-type
Field(s) - @name
-->
<!--
Key Constraint - nodeKey
Selector - ./aif:i-nodes/aif:i-node | ./aif:s-nodes/aif:s-node
Field(s) - @id
-->
<!--
Key Reference Constraint - s-nodeKeyRef
Selector - ./aif:s-nodes/aif:s-node
Field(s) - @type
Refers to - aif:s-typeKey
-->
<!--
Key Reference Constraint - edgeToKeyRef
Selector - ./aif:edges/aif:edge
Field(s) - @to-node
Refers to - aif:nodeKey
-->
<!--
Key Reference Constraint - edgeFromKeyRef
Selector - ./aif:edges/aif:edge
Field(s) - @from-node
Refers to - aif:nodeKey
-->

<aif:context> aif:contextType </aif:context> [1]
<aif:i-nodes> aif:i-nodeCollectionType </aif:i-nodes> [1]
<aif:s-nodes> aif:s-nodeCollectionType </aif:s-nodes> [1]
<aif:edges> aif:edgeCollectionType </aif:edges> [1]
</aif:aif>
Diagram
Schema Component Representation
<xs:element name="aif">
<xs:complexType>
<xs:sequence>
<xs:element name="context" type=" aif:contextType "/>
<xs:element name="i-nodes" type=" aif:i-nodeCollectionType "/>
<xs:element name="s-nodes" type=" aif:s-nodeCollectionType "/>
<xs:element name="edges" type=" aif:edgeCollectionType "/>
</xs:sequence>
</xs:complexType>
<xs:key name="s-typeKey">
<xs:selector xpath="./aif:context/aif:s-types/aif:s-type"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="nodeKey">
<xs:selector xpath="./aif:i-nodes/aif:i-node | ./aif:s-nodes/aif:s-node"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:keyref name="s-nodeKeyRef" refer=" aif:s-typeKey ">
<xs:selector xpath="./aif:s-nodes/aif:s-node"/>
<xs:field xpath="@type"/>
</xs:keyref>
<xs:keyref name="edgeToKeyRef" refer=" aif:nodeKey ">
<xs:selector xpath="./aif:edges/aif:edge"/>
<xs:field xpath="@to-node"/>
</xs:keyref>
<xs:keyref name="edgeFromKeyRef" refer=" aif:nodeKey ">
<xs:selector xpath="./aif:edges/aif:edge"/>
<xs:field xpath="@from-node"/>
</xs:keyref>
</xs:element>
top

Global Definitions

Complex Type: contextType

Super-types: None
Sub-types: None
Name contextType
Abstract no
Documentation This node holds the context of a given AIF message - it is expected to be extended in all implementations In the basic AIF - it provides a placeholder for s-types.
XML Instance Representation
<...>
<aif:s-types> aif:s-typeCollectionType </aif:s-types> [0..1]
</...>
Diagram
Schema Component Representation
<xs:complexType name="contextType">
<xs:sequence>
<xs:element name="s-types" type=" aif:s-typeCollectionType " maxOccurs="1" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
top

Complex Type: edgeCollectionType

Super-types: None
Sub-types: None
Name edgeCollectionType
Abstract no
Documentation A typed collection.
XML Instance Representation
<...>
<aif:edge> aif:edgeType </aif:edge> [0..*]
</...>
Diagram
Schema Component Representation
<xs:complexType name="edgeCollectionType">
<xs:sequence>
<xs:element name="edge" type=" aif:edgeType " minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
top

Complex Type: edgeType

Super-types: None
Sub-types: None
Name edgeType
Abstract no
Documentation An edge simply consists of two attributes, to-node and from-node that must refer to either a an i-node or an s-node id. Implemented as a complexType so that people could extend this node, perhaps you might want to categorise/colour it in order to help users understand a large graph.
XML Instance Representation
<...
from-node=" xs:string [0..1]"
to-node=" xs:string [0..1]"/>
Diagram
Schema Component Representation
<xs:complexType name="edgeType">
<xs:sequence/>
<xs:attribute name="from-node" type=" xs:string "/>
<xs:attribute name="to-node" type=" xs:string "/>
</xs:complexType>
top

Complex Type: i-nodeCollectionType

Super-types: None
Sub-types: None
Name i-nodeCollectionType
Abstract no
Documentation A typed collection.
XML Instance Representation
<...>
<aif:i-node> aif:i-nodeType </aif:i-node> [0..*]
</...>
Diagram
Schema Component Representation
<xs:complexType name="i-nodeCollectionType">
<xs:sequence>
<xs:element name="i-node" type=" aif:i-nodeType " maxOccurs="unbounded" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
top

Complex Type: i-nodeType

Super-types: None
Sub-types: None
Name i-nodeType
Abstract no
Documentation Information or data node.
XML Instance Representation
<...
id=" xs:string [1]">
<aif:text> xs:string </aif:text> [0..1]
</...>
Diagram
Schema Component Representation
<xs:complexType name="i-nodeType">
<xs:sequence>
<xs:element name="text" type=" xs:string " minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type=" xs:string " use="required"/>
</xs:complexType>
top

Complex Type: s-nodeCollectionType

Super-types: None
Sub-types: None
Name s-nodeCollectionType
Abstract no
Documentation A typed collection.
XML Instance Representation
<...>
<aif:s-node> aif:s-nodeType </aif:s-node> [0..*]
</...>
Diagram
Schema Component Representation
<xs:complexType name="s-nodeCollectionType">
<xs:sequence>
<xs:element name="s-node" type=" aif:s-nodeType " minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
top

Complex Type: s-nodeType

Super-types: None
Sub-types: None
Name s-nodeType
Abstract no
Documentation Schema application node. An s-node has an id and a type. Expected to be extended, for instance, in inference one could show grounded rules and/or subsitutions used for defeasible modus ponens.
XML Instance Representation
<...
id=" xs:string [0..1]"
type=" xs:string [0..1]">
<aif:text> xs:string </aif:text> [0..1]
</...>
Diagram
Schema Component Representation
<xs:complexType name="s-nodeType">
<xs:sequence>
<xs:element name="text" type=" xs:string " minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type=" xs:string "/>
<xs:attribute name="type" type=" xs:string "/>
</xs:complexType>
top

Complex Type: s-typeCollectionType

Super-types: None
Sub-types: None
Name s-typeCollectionType
Abstract no
Documentation A typed collection.
XML Instance Representation
<...>
<aif:s-type> aif:s-typeType </aif:s-type> [1..*]
</...>
Diagram
Schema Component Representation
<xs:complexType name="s-typeCollectionType">
<xs:sequence>
<xs:element name="s-type" type=" aif:s-typeType " maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
top

Complex Type: s-typeType

Super-types: None
Sub-types: None
Name s-typeType
Abstract no
Documentation Schema type. Schema types can represent inference application and preference application. the s-node type attribute is expected to match an s-type name attribute.
XML Instance Representation
<...
name=" xs:string [0..1]">
<aif:description> xs:string </aif:description> [1]
</...>
Diagram
Schema Component Representation
<xs:complexType name="s-typeType">
<xs:sequence>
<xs:element name="description" type=" xs:string "/>
</xs:sequence>
<xs:attribute name="name" type=" xs:string "/>
</xs:complexType>
top

Legend

Complex Type:

Schema Component Type

AusAddress

Schema Component Name
Super-types: Address < AusAddress (by extension)
Sub-types:
  • QLDAddress (by restriction)
If this schema component is a type definition, its type hierarchy is shown in a gray-bordered box.
Name AusAddress
Abstract no
The table above displays the properties of this schema component.
XML Instance Representation
<... country="Australia" >
<unitNo> string </unitNo> [0..1]
<houseNo> string </houseNo> [1]
<street> string </street> [1]
Start Choice [1]
<city> string </city> [1]
<town> string </town> [1]
End Choice
<state> AusStates </state> [1]
<postcode> string <<pattern = [1-9][0-9]{3}>> </postcode> [1] ?
</...>

The XML Instance Representation table above shows the schema component's content as an XML instance.

Schema Component Representation
<complexType name="AusAddress">
<complexContent>
<extension base=" Address ">
<sequence>
<element name="state" type=" AusStates "/>
<element name="postcode">
<simpleType>
<restriction base=" string ">
<pattern value="[1-9][0-9]{3}"/>
</restriction>
</simpleType>
</element>
</sequence>
<attribute name="country" type=" string " fixed="Australia"/>
</extension>
</complexContent>
</complexType>
The Schema Component Representation table above displays the underlying XML representation of the schema component. (Annotations are not shown.)
top

Glossary

Abstract (Applies to complex type definitions and element declarations). An abstract element or complex type cannot used to validate an element instance. If there is a reference to an abstract element, only element declarations that can substitute the abstract element can be used to validate the instance. For references to abstract type definitions, only derived types can be used.

All Model Group Child elements can be provided in any order in instances. See: http://www.w3.org/TR/xmlschema-1/#element-all.

Choice Model Group Only one from the list of child elements and model groups can be provided in instances. See: http://www.w3.org/TR/xmlschema-1/#element-choice.

Collapse Whitespace Policy Replace tab, line feed, and carriage return characters with space character (Unicode character 32). Then, collapse contiguous sequences of space characters into single space character, and remove leading and trailing space characters.

Disallowed Substitutions (Applies to element declarations). If substitution is specified, then substitution group members cannot be used in place of the given element declaration to validate element instances. If derivation methods, e.g. extension, restriction, are specified, then the given element declaration will not validate element instances that have types derived from the element declaration's type using the specified derivation methods. Normally, element instances can override their declaration's type by specifying an xsi:type attribute.

Key Constraint Like Uniqueness Constraint, but additionally requires that the specified value(s) must be provided. See: http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions.

Key Reference Constraint Ensures that the specified value(s) must match value(s) from a Key Constraint or Uniqueness Constraint. See: http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions.

Model Group Groups together element content, specifying the order in which the element content can occur and the number of times the group of element content may be repeated. See: http://www.w3.org/TR/xmlschema-1/#Model_Groups.

Nillable (Applies to element declarations). If an element declaration is nillable, instances can use the xsi:nil attribute. The xsi:nil attribute is the boolean attribute, nil, from the http://www.w3.org/2001/XMLSchema-instance namespace. If an element instance has an xsi:nil attribute set to true, it can be left empty, even though its element declaration may have required content.

Notation A notation is used to identify the format of a piece of data. Values of elements and attributes that are of type, NOTATION, must come from the names of declared notations. See: http://www.w3.org/TR/xmlschema-1/#cNotation_Declarations.

Preserve Whitespace Policy Preserve whitespaces exactly as they appear in instances.

Prohibited Derivations (Applies to type definitions). Derivation methods that cannot be used to create sub-types from a given type definition.

Prohibited Substitutions (Applies to complex type definitions). Prevents sub-types that have been derived using the specified derivation methods from validating element instances in place of the given type definition.

Replace Whitespace Policy Replace tab, line feed, and carriage return characters with space character (Unicode character 32).

Sequence Model Group Child elements and model groups must be provided in the specified order in instances. See: http://www.w3.org/TR/xmlschema-1/#element-sequence.

Substitution Group Elements that are members of a substitution group can be used wherever the head element of the substitution group is referenced.

Substitution Group Exclusions (Applies to element declarations). Prohibits element declarations from nominating themselves as being able to substitute a given element declaration, if they have types that are derived from the original element's type using the specified derivation methods.

Target Namespace The target namespace identifies the namespace that components in this schema belongs to. If no target namespace is provided, then the schema components do not belong to any namespace.

Uniqueness Constraint Ensures uniqueness of an element/attribute value, or a combination of values, within a specified scope. See: http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions.

top