Extensions

Extensions to FLAP are classified into two groups. Different access technologies may require an extension to the protocol in order to transport either terminal or access information. In addition, specific vendors may have proprietary information that may add to the quality or efficiency of location determination methods. A new access technology warrants more detailed specification than the proprietary extension, so both of these cases are accommodated by this section.

Extensions are differentiated by the use of XML namespaces (see Reference 4).

Access Technology Extensions

This protocol is designed to be extended for use in different access technologies, which necessitates different sets of both access and terminal data. Definitions for DHCP and Ethernet technologies are included in the base specification, but this is by no means exhaustive. Extensions for additional access technologies may be made by defining an XML schema in a new namespace.

Technologies are identified by a short identifier, like "ethernet," that is included in each message. This enables the management of multiple technologies from a single LIS, or even from a single ALE, although that is not encouraged.

The most basic extension defines a set of XML elements that are to be used for access and terminal data. Since both the terminal and access elements permit any content, these can be included as necessary. This minimal form of technology extension is very similar to what an individual vendor might do to include their extension.

A more complete extension also provides new type definitions for access and terminal elements so that their cardinality can be controlled. Extensions in this fashion are optional, but offer greater control over the encoding of messages. By using the restriction rules of XML schema, the extension can ensure that the correct information is provided in a predictable format.

Terminal and Access Definitions

The most primitive extension method derives schema for the terminal and access elements by restriction from the base types. The terminalType and accessType type definitions are derived by restriction into type definitions for the access technology.

For example, the Ethernet extension defines the following types for terminal and access elements.

 <xsd:element name="terminal" type="terminalType"              substitutionGroup="flap:terminal"/> <xsd:complexType name="terminalType">   <xsd:comp1exContent>     <xsd:restriction base="f1ap:termina1Type">       <xsd:sequence>         <xsd:choice>           <xsd:sequence>             <xsd:element ref="flap:ip"/>             <xsd:element ref="mac" minOccurs="0"/>           </xsd:sequence>           <xsd:element ref="mac"/>         </xsd:choice>         <xsd:element ref="flap:_ vendor"                      minOccurs="0" maxOccurs="unbounded"/>       </xsd:sequence>     </xsd:restriction>   </xsd:complexContent> </xsd:comp1exType> <xsd:element name="access" type="accessType"             substitutionGroup="flap:access"/> <xsd:complexType name="accessType">   <xsd:complexContent>     <xsd:restriction base="flap:accessType">       <xsd:sequence minOccurs="0">         <xsd:element ref="switch"/>         <xsd:element ref="port"/>         <xsd:element ref="vlan" minOccurs="0"/>         <xsd:element ref="flap:_vendor"                      minOccurs="0" maxOccurs="unbounded"/>       </xsd:sequence>     </xsd:restriction>   </xsd:complexContent> </xsd:complexType> 

This schema defines the types that make up terminal identification and access data. This schema also defines a new element type for both terminal and access, which are substitutable for the base elements. Both of these definitions permit vendor-specific content through the flap:_vendor element, as described in the later section titled "Vendor-Specific Content."

This results in a message that uses these elements. The following example shows an intermediate form of a Notification:

 <ntfy tech="ethernet">   <enet:terminal>     <ip>192.168.0.1</ip>     <enet:mac>12:34:56:78:90:ab</enet:mac>   </enet:terminal>   <enet:access time="2005-04-14T10:51:23.000 + 10:00 ">     <enet:switch><ip>192.168.0.1</ip></enet:switch>     <enet:port>4</enet:port>   </enet:access> </ntfy> 

Message Definitions

Restricting the types for terminal and access is sufficient to ensure that validation is applied correctly to the new elements. However, this does not ensure consistency across the entire message. In other words, validation of a message using individual types does not ensure that a terminal element is associated with the same technology as its matched access element. This section describes how to both simplify message instances and to guarantee consistency of technology application within each type.

A derived message type may be defined by restricting the core message type definitions. The new message type restricts the terminal and access elements to use the types defined for that access technology. Because this new type is applied to the message as a whole, the terminal and access elements implicitly receive the correct type definition.

The new Notification message definition for Ethernet is

 <xsd:attributeGroup name="techAttr">   <xsd:attribute name="tech" type="xsd:anyURI" fixed="ethernet"/> </xsd:attributeGroup> <xsd:complexType name="ntfy">   <xsd:complexContent>     <xsd:restriction base="flap:ntfyType">       <xsd:sequence>         <xsd:element ref="terminal"/>         <xsd:element ref="access"/>       </xsd:sequence>       <xsd:attributeGroup ref="techAttr"/>     </xsd:restriction>   </Xsd:complexContent> </xsd:complexType> 

The extension definition also sets the tech attribute to a fixed value of "ethernet". One notable feature of this method is that the code for restricting message types is almost identical for all types of technology extension. The technology extensions in this document only differ in the fixed value assigned to the tech attribute.

An instance of a Notification message using the newly defined type looks like:

 <ntfy xsi:type="enet:ntfy">   <enet:terminal>     <ip>192.168.0.1</ip>     <enet:mac>12:34:56:78:90:ab</enet:mac>   </enet:terminal>   <enet:access time="2005-04-14T10:51:23.000+10:00">     <enet:switch><ip>192.168.0.1</ip></enet:switch>     <enet:port>4</enet:port>   </enet:access> </ntfy> 

Note that other access technology extensions will use a different namespace for their new elements, as well as the xsi:type attribute.

Additional Message Types

Message elements all belong to a substitution group, the head of which is an abstract element named _message. New message types are defined by extending the type definition, messageType, and creating a new element of this type that belongs to the _message substitution group. The following definition describes an example message that contains a new "host" element:

 <xsd:element name="example" substitutionGroup="_message">   <xsd:complexType>     <xsd:complexContent>       <xsd:extension base="f1ap:messageType">         <xsd:element name="host" type="flap:ipAddress"/>       </xsd:extension>     </xsd:complexContent>   </xsd:complexType> </xsd:element> 

Given that the preceding example is defined in the ",urn: example" namespace, this leads to the following new message:

 <example xmlns:ex="urn:example">   <host>47.153.203.21</host> </example> 

Vendor-Specific Content

Vendor-specific content should be permitted by technology extensions through the _vendor element. Vendor extensions are made by defining a new element in the substitution group headed by the _vendor element. These elements are defined in a new namespace and schema. The optional attribute on this element should include a URI that uniquely identifies a vendor, which may be the same as the namespace URI.

A receiver should ignore the contents of messages that it does not understand. Errors in XML well formedness always result in errors.

The namespace prefix for the vendor extension can either be declared with the ns-prefix element, or declared when used. The following example assumes that the exco: prefix has been declared previously.

 <ntfy xsi:type="enet:ntfy">   <enet:terminal>     <ip>192.168.0.1</ip>     <enet:hwaddr>12:34:56:78:90:ab</enet:hwaddr>     <exco:hw serial="167332" revision="1.2"/>   </enet:terminal>   <enet:access time="2005-04-14T10:51:23.000+10:00">     <enet:switch><ip>192.168.0.1</ip></enet:switch>     <enet:port>4</enet:port>   </enet:access> </ntfy> 

The exco:hw element in the preceding example sets a fixed value for the flap:vendor attribute in its XML schema definition. The following XML schema fragment defines this vendor extension:

 <xsd:element name="hw" type="hwType"              substitutionGroup="flap:_vendor"/> <xsd:complexType name="hwType">   <xsd:complexContent>     <xsd:restriction base="flap:vendorExtensionType">       <xsd:attribute ref="flap:vendor"                      fixed="http://exampleco.com/"/>       <xsd:attribute name="serial" type="xsd:token"/>       <xsd:attribute name="revision" use="required">         <xsd:simpleType>           <xsd:restriction base="xsd:normalizedString">             <xsd:pattern value="\w+(\.\w+)*"/>           </xsd:restriction>         </xsd:simpleType>       </xsd:attribute>     </xsd:restriction>   </xsd:complexContent> </xsd:complexType>