Application Server Logging Specification (ASLS)

VoiceXML Forum, Tools Working Group
Draft 1.5 - Internal Working Draft - 31 July 2007
For Public Review 20 August 2007

Editor:

Bogdan Blaszczak, Intervoice

About the VoiceXML Forum:

Founded in 1999, the VoiceXML Forum is an industry organization whose mission is to promote and to accelerate the worldwide adoption of VoiceXML-based applications. To this end, the Forum serves as an educational and technical resource, a certification authority and a contributor and liaison to international standards bodies, such as the World Wide Web Consortium (W3C) IETF, ANSI and ISO. The VoiceXML Forum is organized as a program of the IEEE Industry Standards and Technology Organization (IEEE-ISTO). Membership in the Forum is open to any interested company. For more information, please visit the Website at www.voicexml.org.

Disclaimers:

This document is subject to change without notice and may be updated, replaced or made obsolete by other documents at any time. The VoiceXML Forum disclaims any and all warranties, whether express or implied, including (without limitation) any implied warranties of merchantability or fitness for a particular purpose.

The descriptions contained herein do not imply the granting of licenses to make, use, sell, license or otherwise transfer any technology required to implement systems or components conforming to this specification. The VoiceXML Forum, and its member companies, makes no representation on technology described in this specification regarding existing or future patent rights, copyrights, trademarks, trade secrets or other proprietary rights.

By submitting information to the VoiceXML Forum, and its member companies, including but not limited to technical information, you agree that the submitted information does not contain any confidential or proprietary information, and that the VoiceXML Forum may use the submitted information without any restrictions or limitations.

Table of Contents

Introduction

History:

Mar 06, 2007: Draft 1.0
Mar 13, 2007: Draft 1.1
Apr 03, 2007: Draft 1.2
Apr 24, 2007: Draft 1.3
Jul 17, 2007: Draft 1.4
Jul 31, 2007: Draft 1.5 - see the Changes appendix.

Introduction

This document defines a format for high-level logging on application servers. The log information conforming to the Application Server Logging Specification (ASLS) should be embedded in a Session Log Annotation Markup Language (SLAML) document.

The SLAML document aggregates logs from all the collaborating entities, including browsers and servers. The server-side logging should complement the browser logs and provide visibility to the actions and decisions involved in handling browser requests. The server-side logging reflects the application logic flow rather than the run-time environment details.

General Model

The Application Server Logging Specification (ASLS) is based on a high-level model of the application processing. The model assumes a web-like processing environment that consists of browsers and servers. This is congruent with the VoiceXML and CCXML environments.

The abstractions used in ASLS are independent of any specific implementation of server-side applications. The abstractions capture information sufficient for application-level, business-oriented reporting or other, similar post-processing. ASLS is not a substitute for the run-time trace logs.

Sessions

The server-side application is usually triggered by a request from a browser. The association between browser requests and an application instance is achieved through a session identifier that is attached to each browser request using one of the established web technologies (e.g. cookies).

The session tag encapsulates the log content produced by all the processing steps within the server-side session. The session identifier is captured as the tag attribute.

The session tag should also be used when browser requests are responded to by either a stateless application or by the platform web server that retrieves static files. The session ID attribute can be omitted to indicate a session-less processing. In the case of static files, the log content can be produced by post-processing of the common web log. However, this may not add much value to an aggregated SLAML document.

Segments

The period of processing required to produce the response to a browser request is called a segment. The segment notation uses SLAML attributes prescribed for a period element.

In some cases, the server-side processing may need to extend beyond a single query/response cycle. In ASLS, this is captured by means of additional segments that refer back to the segments that spawned them. The segments will usually proceed in parallel.

Segments contain request and response elements that describe the input and output of the segment. Segments may also contain action and decision elements that provide details of the segment processing.

Actions and Decisions

The ASLS uses actions and decisions as the general abstractions for application processing within a segment.

In the SLAML terms, an action is a period and a decision is an event. The implied nesting rules are as followed:

An action element may contain other action elements and data elements.
A decision element may only contain data elements.

The reporting of actions and decisions is the result of application instrumentation. This may be done automatically by the server-side execution environment or it may be left for the application programmer to do explicitly.

The following two examples show how the ASLS abstractions can be mapped to a flow diagram and a state machine.

Let's first consider the following application flow:

app flow

The execution proceeding through the above flow may log the following information:

action(CheckCredentials)
decision(ValidUser.No)
action(TransferToAgent)

The same application fragment may be represented as a state machine:

app states

In this case, the log information may look as follows:

action(CheckCredentials)
decision(Invalid)
action(TransferToAgent)

It is reasonable to expect that different implementation environments will have different concepts of what constitutes and action or a decision. However, these two abstractions should be sufficient to capture the application-level logs in an implementation-independent way.

Concurrent Actions

The modern application environments usually support some type of parallel execution, e.g. multi-threading or parallel states. This can be used not only to spawn a parallel segment of the application processing (as described previously), but it may also be used within a segment to let actions execute in parallel.

In ASLS, the parallel execution of actions is indicated by the "parallel" value of the SLAML mode attribute of the parent tag. The parent can be a segment or an actions. The parallel property applies to the immediate children.

Data Elements

The segment, action, and decision elements may contain data elements that capture input or output of the corresponding processing. The SLAML view is that any element without a timing information is a data element.

Embedding ASLS within SLAML

ASLS log records will be embedded within the SLAML sl:log tag.

Extending ASLS Log Format

ASLS log records can be extended at the following points:

Additional attributes (from a separate namespace) are allowed at all the ASLS tags.
<data> tag can hold any content.

ASLS Elements

This section defines elements and attributes allowed in ASLS. The attributes or elements from the SLAML namespace are prefixed with sl:

The Session Element: `session`

Element	`session`
Description	This element is the top level container of the ASLS content. The `sl:log` element may contain multiple sessions. This may be required for servers handling both CCXML and VoiceXML browsers. The sessions should always be considered parallel.
Attributes	Required: `sl:start` specifies the start time of the session. `sl:end` specifies the end time of the session. Optional: `sessionID` specifies a session identifier, if available `name` specifies a session name `sl:mode` when set to "parallel", it indicates that the contained segments were executing in parallel any attributes from a different namespace (this is an extension point)
Children	Zero or one `input` elements. Zero or more `segment` elements. Zero or one `result` elements.
Parent	`sl:log`

For example,

<sl:log ... xmlns="http://voicexml.org/2006/asls-slaml" sl:version="1.0">
 <session ... >
 ...
 </session>
</sl:log>

The Segment Element: `segment`

Element	`segment`
Description	Contains log information about the segment data and processing steps.
Attributes	Required: `sl:handle-interaction` specifies the interaction identifier provided by the entity that requested processing represented by the segment. . `sl:start` specifies the start time of the segment. `sl:end` specifies the end time of the segment Optional: `name`: segment name `sl:mode` when set to "parallel", it indicates that the contained actions were executing in parallel. `sl:source` provides an address of the entity that request processing represented by the segment. any attributes from a different namespace (this is an extension point)
Children	Zero or one `input` elements. Zero or more `action` or `decision` elements. Zero or one `result` elements.
Parent	`session`

The segment element contains all the data and processing logs produced while the server worked on a response. In the SLAML terms, the segment is an interaction handler.

During processing, a new segment may be started for internal reasons. The same interaction identifier must be specified in the attributes of the corresponding call and

segment

elements to properly record the association.

For example,

<segment ... >
 <input ... > ... </input>
 <action ...> ... </action>
 <decision ...> ... </decision>
 <result ...> ... </result>
</segment>

The Action Element: `action`

Element	`action`
Description	Contains log records of action data and any sub-actions or decisions. If the action element is a interaction handler, the optional SLAML attributes must be used.
Attributes	Required: `name`: action name `sl:start` specifies the start time of the action. `sl:end` specifies the end time of the action Optional: `sl:handle-interaction` specifies the interaction identifier provided by the entity that requested processing represented by the action. . `sl:source` provides an address of the entity that request processing represented by the action. any attributes from a different namespace (this is an extension point)
Children	Zero or one `input` elements. Zero or more `action` or `decision` elements. Zero or one `result` elements.
Parent	`segment` or `action`

The Decision Element: `decision`

Element	`decision`
Description	Contains log information about a processing decision.
Attributes	Required: `name`: action name `sl:time` specifies the time of the decision. Optional: any attributes from a different namespace (this is an extension point)
Children	Zero or one `input` elements. Zero or one `result` elements.
Parent	`segment` or `action`

The Call Element: `call`

Element	`call`
Description	It is a SLAML period element that represents the sending of the request and the receipt of the associated response. It may also contain any related, caller-side processing done in the interim.
Attributes	Required: `name` call name `sl:start` specifies the start time of the call. `sl:end` specifies the end time of the call `sl:interaction` specifies the interaction identifier `sl:log-tag` a log tag value that enables log record association `sl:class` a type of entity to be call target Optional: `sl:target` an address of the target, if applicable any attributes from a different namespace (this is an extension point)
Children	Zero or one `input` elements. Zero or one `param` elements. Zero or more `action` or `decision` elements. Zero or one `result` elements.
Parent	`segment` or `action`

The Input Element: `input`

Element	`input`
Description	Contains a list of input data of the parent element.
Attributes	Optional: `name`: element name any attributes from a different namespace (this is an extension point)
Children	Zero or more `data` elements.
Parent	`segment`, `action`, `decision` ,or `call`

The Result Element: `result`

Element	`result`
Description	Contains a list data results that the parent element produced or concluded.
Attributes	Optional: `name`: element name any attributes from a different namespace (this is an extension point)
Children	Zero or more `data` elements.
Parent	`segment`, `action`, `decision` ,or `call`

The Param Element: `param`

Element	`param`
Description	Contains a list of parameter data passed by the parent element to the target.
Attributes	Optional: `name`: element name any attributes from a different namespace (this is an extension point)
Children	Zero or more `data` elements.
Parent	`call`

The Data Element: `data`

Element	`data`
Description	Defines a named data element of the parent.
Attributes	Required: `name`: data name Optional: `type`: specifies the data type. String is the default type. Other types are Number, URI, mime type. any attributes from a different namespace (this is an extension point)
Children	Any content that represent data value (xsd anyType child)
Parent	`input`, `result`, or `param`

Appendix A: Examples

The first example shows a log of simple, sequential processing. Please notice a VoiceXML snippet contained in the <result> of the <segment>. This is an example of extending the log content with elements of other namespaces.

<?xml version="1.0" encoding="UTF-8"?>
<sl:slaml xmlns:sl="http://voicexml.org/2006/slaml" version="1.0" 
      xsi:schemaLocation="http://voicexml.org/2006/slaml  voicexml.org/2006/slaml.xsd" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <sl:manifest>
        <sl:session name="AS1-abcd" origin="1234" sl:class="ApplicationServer" sl:log-tag="as-log-1"/>
    </sl:manifest>
    <sl:log tag="as-log-1" sl:class="ApplicationServer" entity="AS-1" 
            xmlns:as="http://voicexml.org/2006/asls-slaml" 
            xsi:schemaLocation="http://voicexml.org/2006/asls-slaml voicexml.org/2006/asls-slaml.xsd">
        <!-- ASLS content -->
        <as:session as:sessionID="a1234" sl:start="1" sl:end="40">
            <as:segment sl:handle-interaction="1234" sl:start="2" sl:end="100">
                <as:input>
                    <as:data as:name="URI" as:type="URI"> http://as1.xyz.int/main </as:data>
                    <as:data as:name="userAgent"> VoiceXML/2.1 (VB 3.5; Linux) </as:data>
                </as:input>
                <!-- 'single-threaded' processing -->
                <as:action as:name="CheckCredentials " sl:handle-interaction="" sl:start="3" sl:end="20"/>
                <as:decision as:name="ValidUser" sl:time="21">
                    <as:result>
                        <as:data as:name="authorization">invalid</as:data>
                    </as:result>
                </as:decision>
                <as:action as:name="TransferToAgent" sl:handle-interaction="" sl:start="22" sl:end="35">
                    <as:input>
                        <as:data as:name="agentSkills">newAccounts</as:data>
                    </as:input>
                </as:action>
                <as:result>
                    <as:data as:name="response" as:type="application/voicexml+xml">
                        <vxml xmlns="http://www.w3.org/2001/vxml" version="2.1">
                            <form>
                                <block>Please wait while we transfer you to the agent</block>
                            </form>
                        </vxml>
                    </as:data>
                </as:result>
            </as:segment>
        </as:session>
    </sl:log>
</sl:slaml>

The following log illustrates a processing flow of an auction server. A new (and only) bid triggers a segment that defers the bid placement to a parallel segment that maintains the auction state. All the processing is handled within the same entity.

<?xml version="1.0" encoding="UTF-8"?>
<sl:slaml xmlns:sl="http://voicexml.org/2006/slaml" version="1.0" 
        xsi:schemaLocation="http://voicexml.org/2006/slaml  voicexml.org/2006/slaml.xsd" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <sl:manifest>
        <sl:session name="AS2-abcd" origin="vb1-1234" sl:class="AuctionServer" sl:log-tag="as-log-2"/>
    </sl:manifest>
    <sl:log tag="as-log-2" sl:class="AuctionServer" entity="AS-2" 
           xmlns:as="http://voicexml.org/2006/asls-slaml" 
           xsi:schemaLocation="http://voicexml.org/2006/asls-slaml voicexml.org/2006/asls-slaml.xsd">
        <!-- a bid placement  -->
        <as:session as:sessionID="as-b1" sl:start="90" sl:end="99">
            <as:segment sl:handle-interaction="vb1-1234" sl:start="90" sl:end="99">
                <as:input>
                    <as:data as:name="URI" as:type="URI"> http://as2.vgs.int/bid"</as:data>
                    <as:data as:name="userAgent"> VoiceXML/2.1 (VB 3.5; Linux) </as:data>
                </as:input>
                <as:call as:name="NewBid" sl:interaction="bid-1" sl:log-tag="as-log-2" 
                        sl:class="AuctionServer" sl:start="91" sl:end="98">
                    <as:input>
                        <as:data as:name="auctionID" as:type="Number"> 777 </as:data>
                        <as:data as:name="bid" as:type="Number"> 333 </as:data>
                    </as:input>
                    <as:result>
                        <as:data as:name="receipt"> 777-1</as:data>
                    </as:result>
                </as:call>
                <as:result>
                    <as:data as:name="response" type="application/voicexml+xml">
                        <vx:vxml xmlns:vx="http://www.w3.org/2001/vxml" vx:version="2.1">
                            <vx:form>
                                <vx:block>Bid accepted. Confirmation 777-1</vx:block>
                            </vx:form>
                        </vx:vxml>
                    </as:data>
                </as:result>
            </as:segment>
        </as:session>
        <!-- an auction session -->
        <as:session as:sessionID="as-a1" sl:start="1" sl:end="110" sl:mode="parallel">
            <as:segment as:name="NewBid" sl:handle-interaction="bid-1" sl:start="92" sl:end="97">
                <as:input>
                    <as:data as:name="auctionID" as:type="Number"> 777 </as:data>
                    <as:data as:name="bid" as:type="Number"> 333 </as:data>
                </as:input>
                <as:decision as:name="DisplayReservePrice" sl:time="93"/>
                <as:decision as:name="AddOvertime" sl:time="94"/>
                <as:result>
                    <as:data as:name="confirmationID">777-1</as:data>
                </as:result>
            </as:segment>
            <as:segment sl:handle-interaction="admin-1" as:name="Auction" sl:start="1" sl:end="110">
                <as:action as:name="InitializeAuction" sl:handle-interaction="" sl:start="1" sl:end="2">
                    <as:input>
                        <as:data as:name="ReservePrice" as:type="Number">300</as:data>
                        <as:data as:name="Duration" as:type="Number">100</as:data>
                    </as:input>
                    <as:result>
                        <as:data as:name="auctionID">777</as:data>
                    </as:result>
                </as:action>
                <as:action as:name="FinalizeAuction" sl:handle-interaction="" sl:start="108" sl:end="109">
                    <as:result>
                        <as:data as:name="winner">777-1</as:data>
                    </as:result>
                </as:action>
            </as:segment>
        </as:session>
    </sl:log>
</sl:slaml>

The next example shows a variation of the previous auction processing flow where the system consists of of two servers. The first one is a server that provides the auction bid UI and the second one is an auction hub that arbitrates bids.

<?xml version="1.0" encoding="UTF-8"?>
<sl:slaml xmlns:sl="http://voicexml.org/2006/slaml" version="1.0" 
       xsi:schemaLocation="http://voicexml.org/2006/slaml  voicexml.org/2006/slaml.xsd" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <sl:manifest>
        <sl:session name="AS2-abcd" origin="vb1-1234" sl:class="AuctionServer" sl:log-tag="as-log-2"/>
        <sl:session name="AS3-abcd" origin="auction-5678" sl:class="AuctionHub" sl:log-tag="as-log-3"/>
    </sl:manifest>
    <sl:log tag="as-log-2" sl:class="AuctionServer" entity="AS-2" 
          xmlns:as="http://voicexml.org/2006/asls-slaml" 
          xsi:schemaLocation="http://voicexml.org/2006/asls-slaml voicexml.org/2006/asls-slaml.xsd">
        <!-- a bid placement  -->
        <as:session as:sessionID="as-b1" sl:start="90" sl:end="99">
            <as:segment sl:handle-interaction="vb1-1234" sl:start="90" sl:end="99">
                <as:input>
                    <as:data as:name="URI" type="URI"> http://as2.vgs.int/bid"</as:data>
                    <as:data as:name="userAgent"> VoiceXML/2.1 (VB 3.5; Linux) </as:data>
                </as:input>
                <as:call as:name="NewBid" sl:interaction="bid-1" sl:class="AuctionServer" 
                       sl:log-tag="as-log-3" sl:start="91" sl:end="98">
                    <as:input>
                        <as:data as:name="auctionID" as:type="Number"> 777 </as:data>
                        <as:data as:name="bid" as:type="Number"> 333 </as:data>
                    </as:input>
                    <as:result>
                        <as:data as:name="receipt"> 777-1</as:data>
                    </as:result>
                </as:call>
                <as:result>
                    <as:data as:name="response" as:type="application/voicexml+xml">
                        <vx:vxml xmlns:vx="http://www.w3.org/2001/vxml" vx:version="2.1">
                            <vx:form>
                                <vx:block>Bid accepted. Confirmation 777-1</vx:block>
                            </vx:form>
                        </vx:vxml>
                    </as:data>
                </as:result>
            </as:segment>
        </as:session>
    </sl:log>
    <sl:log tag="as-log-3" sl:class="AuctionHub" entity="AS-3" xmlns:as="http://voicexml.org/2006/asls-slaml">
        <!-- an auction hub session -->
        <as:session as:sessionID="as-a1" sl:start="1" sl:end="110" sl:mode="parallel">
            <as:segment as:name="NewBid" sl:handle-interaction="bid-1" sl:start="92" sl:end="97">
                <as:input>
                    <as:data as:name="auctionID" as:type="Number"> 777 </as:data>
                    <as:data as:name="bid" as:type="Number"> 333 </as:data>
                </as:input>
                <as:decision as:name="DisplayReservePrice" sl:time="93"/>
                <as:decision as:name="AddOvertime" sl:time="94"/>
                <as:result>
                    <as:data as:name="confirmationID">777-1</as:data>
                </as:result>
            </as:segment>
            <as:segment sl:handle-interaction="admin-1" as:name="Auction" sl:start="1" sl:end="110">
                <as:action as:name="InitializeAuction" sl:handle-interaction="auction-5678" sl:start="1" sl:end="2">
                    <as:input>
                        <as:data as:name="ReservePrice" as:type="Number">300</as:data>
                        <as:data as:name="Duration" as:type="Number">100</as:data>
                    </as:input>
                    <as:result>
                        <as:data as:name="auctionID">777</as:data>
                    </as:result>
                </as:action>
                <as:action as:name="FinalizeAuction" sl:handle-interaction="" sl:start="108" sl:end="109">
                    <as:result>
                        <as:data as:name="winner">777-1</as:data>
                    </as:result>
                </as:action>
            </as:segment>
        </as:session>
    </sl:log>
</sl:slaml>

Appendix B: ASLS Schema

Below is the ASLS schema definition. Please notice the slaml-base.xsd is imported to provide the standard SLAML attributes.
This is still a preliminary schema that requires further refinement.
However, the examples in this document have been validated against it.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://voicexml.org/2006/asls-slaml" 
       xmlns:sl="http://voicexml.org/2006/slaml" 
       xmlns:xs="http://www.w3.org/2001/XMLSchema" 
       xmlns:as="http://voicexml.org/2006/asls-slaml" 
       elementFormDefault="qualified" attributeFormDefault="qualified" version="1.0">
    <xs:import namespace="http://voicexml.org/2006/slaml" schemaLocation="slaml-base.xsd"/>
    <xs:element name="session">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="as:input" minOccurs="0"/>
                <xs:element ref="as:segment" minOccurs="0" maxOccurs="unbounded"/>
                <xs:element ref="as:result" minOccurs="0"/>
            </xs:sequence>
            <xs:attributeGroup ref="as:periodGroup"/>
            <xs:attribute ref="as:sessionID" use="optional"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="segment">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="as:input" minOccurs="0"/>
                <xs:group ref="as:activityLog"/>
                <xs:element ref="as:result" minOccurs="0"/>
            </xs:sequence>
            <xs:attributeGroup ref="as:periodGroup"/>
            <xs:attributeGroup ref="sl:interaction-handler"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="action">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="as:input" minOccurs="0"/>
                <xs:group ref="as:activityLog"/>
                <xs:element ref="as:result" minOccurs="0"/>
            </xs:sequence>
            <xs:attributeGroup ref="as:periodGroup"/>
            <xs:attributeGroup ref="sl:interaction-handler"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="decision">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="as:input" minOccurs="0"/>
                <xs:element ref="as:result" minOccurs="0"/>
            </xs:sequence>
            <xs:attributeGroup ref="as:eventGroup"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="call">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="as:input" minOccurs="0"/>
                <xs:element ref="as:param" minOccurs="0"/>
                <xs:group ref="as:activityLog"/>
                <xs:element ref="as:result" minOccurs="0"/>
            </xs:sequence>
            <xs:attributeGroup ref="as:periodGroup"/>
            <xs:attributeGroup ref="sl:interaction"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="input">
        <xs:complexType>
            <xs:group ref="as:dataList"/>
            <xs:attribute ref="as:name" use="optional"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="result">
        <xs:complexType>
            <xs:group ref="as:dataList"/>
            <xs:attribute ref="as:name" use="optional"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="param">
        <xs:complexType>
            <xs:group ref="as:dataList"/>
            <xs:attribute ref="as:name" use="optional"/>
            <xs:attributeGroup ref="as:anyAttribute"/>
        </xs:complexType>
    </xs:element>
    <xs:element name="data">
        <xs:complexType>
            <xs:complexContent>
                <xs:extension base="xs:anyType">
                    <xs:attribute ref="as:name" use="required"/>
                    <xs:attribute ref="as:type" use="optional"/>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:element>
    <xs:group name="dataList">
        <xs:sequence>
            <xs:element ref="as:data" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:group>
    <xs:group name="activityLog">
        <xs:sequence>
            <xs:choice minOccurs="0" maxOccurs="unbounded">
                <xs:element ref="as:action"/>
                <xs:element ref="as:call"/>
                <xs:element ref="as:decision"/>
            </xs:choice>
        </xs:sequence>
    </xs:group>
    <xs:attribute name="name" type="xs:NMTOKEN"/>
    <xs:attribute name="type"/>
    <xs:attribute name="sessionID" type="xs:string"/>
    <xs:attributeGroup name="periodGroup">
        <xs:attribute ref="as:name" use="optional"/>
        <xs:attributeGroup ref="sl:period"/>
    </xs:attributeGroup>
    <xs:attributeGroup name="eventGroup">
        <xs:attribute ref="as:name" use="optional"/>
        <xs:attributeGroup ref="sl:event"/>
    </xs:attributeGroup>
    <xs:attributeGroup name="anyAttribute">
        <xs:anyAttribute namespace="##other"/>
    </xs:attributeGroup>
</xs:schema>

Appendix C: ASLS MIME Type

Appendix D: Open Issues

The following issues remain open:

Need to revisit schema definitions and resulting XML validation - XML tools does not completely agree on what is valid.
Add schema documentation, refine handling of 'any' to require 'other' namespaces.
Verify proper handling of parallel and sequential.
Should we define any standard types of data elements ?
Can we standardize the request ID passing over HTTP (à la sessionid of JSPs)?
Should <call> embed other actions? Will timing work (<call> period)? Would an additional interaction (segment ?) be a better model ?

Appendix E: Changes

Draft 1.5:

Validated examples with XML Spy 2007, but other tools still complain. See open issues.
Changed attributeFormDefault of ASLS schema to "qualified".

Draft 1.4:

Added log extension paragraph and the corresponding any attribute.
Synchronized description with the schema.

Draft 1.3:

Changed sl:request and sl:request-handler to interaction attributes per SLAML spec.
Replaced <request> with <input> to better indicate what the contained data represents.
Added the <param> element which can be contained by <call>.
Added a preliminary xsd and validated examples.

Draft 1.2:

Fixed the notation and reference IDs in the examples
Added an example of the multi-session notation log file.

Draft 1.1:

Added fixes and resolutions to the 1.0 open issues:

Applied SLAML terminology.

Defined logging for processing that extends beyond individual transactions.

Described how how the logging abstractions can be applied to a flow diagram and a state machine as examples of server-side implementation technologies.

Provided explanation of how <session> can be used to represent a 'default' session of a server.

Provided two log examples.

The following 1.0 open issue was deemed outside of the scope of this document:

Do we have enough information to provide good usability reports? Should we have ‘business level’ transaction markers beyond the current reflection of HTTP transactions?
Since the <data> elements allow arbitrary additional information to be included, the current format should not significantly constrain logging of any business-level "markers".
Replaced <send> tag with a <call> tag with sl:request.

Appendix F: Acknowledgments

Appendix G: References

Copyright © 2000 - 2007 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE Industry Standards and Technology Organization (IEEE-ISTO)
For inquiries contact voicexml-admin@voicexml.org