Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The W3C Voice Browser working group aims to develop specifications to enable access to the Web using spoken interaction. This document is part of a set of requirement studies for voice browsers, and provides details of the requirements for marking up spoken dialogs.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the 8 August 2008 W3C Working Draft of "Voice Extensible Markup Language (VoiceXML) 3.0 Requirements".
This document describes the requirements for marking up dialogs for spoken interaction required to fulfill the charter given in the Voice Browser Working Group Charter, and indicates how the W3C Voice Browser Working Group has satisfied these requirements via the publication of working drafts and recommendations. This is a First Public Working Draft. The group does not expect this document to become a W3C Recommendation.
This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group. You are encouraged to subscribe to the public discussion list<EMAIL_ADDRESS>and to mail us your comments. To subscribe, send an email to<EMAIL_ADDRESS>with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). A public archive is available online.
This specification is a Working Draft of the Voice Browser working group for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The main goal of this activity is to establish the current status of the Voice Browser Working Group Activities relative to the requirements defined in Previous Requirements Document and define additional requirements to drive future Voice Browser Working Group activities based on Voice Community experience with existing standards
The process will consist of the following steps:
The previous requirements definition activity focused on defining three types of requirements on the voice markup language: modality, functional, and format.
The environment and capabilities of the voice browser interpreting the markup language affects these requirements. There may be differences in the modality and functional requirements for desktop versus telephony-based environments (and in the latter case, between fixed, mobile and Internet telephony environments). The capabilities of the voice browser device also impacts on requirements. Requirements affected by the environment or capabilities of the voice browser device will be explicitly marked as such.
Although defining a dialog is highly problematic, some basic definitions
must be provided to establish a common basis of understanding and avoid
confusion. The following terminology is based upon an event-driven model of
dialog interaction.
| Voice Markup Language | a language in which voice dialog behavior is specified. The language may include reference to style and scripting elements which can also determine dialog behavior. |
|---|---|
| Voice Browser | a software device which interprets a voice markup language and generates a dialog with voice output and/or input, and possibly other modalities. |
| Dialog | a model of interactive behavior underlying the interpretation of the markup language. The model consists of states, variables, events, event handlers, inputs and outputs. |
| State | the basic interactional unit defined in the markup language; for example, an < input > element in HTML. A state can specify variables, event handlers, outputs and inputs. A state may describe output content to be presented to the user, input which the user can enter, event handlers describing, for example, which variables to bind and which state to transition to when an event occur. |
| Events | generated when a state is executed by the voice browser; for example, when outputs or inputs in a state are rendered or interpreted. Events are typed and may include information; for example, an input event generated when an utterance is recognized may include the string recognized, an interpretation, confidence score, and so on. |
| Event Handlers | are specified in the voice markup language and describe how events generated by the voice browser are to be handled. Interpretation of events may bind variables, or map the current state into another state (possibly itself). |
| Output | content specified in an element of the markup language for presentation to the user. The content is rendered by the voice browser; for example, audio files or text rendered by a TTS. Output can also contain parameters for the output device; for example, volume of audio file playback, language for TTS, etc. Events are generated when, for example, the audio file has been played. |
| Input | content (and its interpretation) specified in an element of the markup language which can be given as input by a user; for example, a grammar for DTMF and speech input. Events are generated by the voice browser when, for example, the user has spoken an utterance and variables may be bound to information contained in the event. Input can also specify parameters for the input device; for example, timeout parameters, etc. |
The dialog requirements for the voice markup language are annotated with
the following priorities. If a feature is deferred from the initial
specification to a future release, consideration may be given to leaving open
a path for future incorporation of the feature.
| must have | The first official specification must define the feature. |
|---|---|
| should have | The first official specification should define the feature if feasible but may defer it until a future release. |
| nice to have | The first official specification may define the feature if time permits, however, its priority is low. |
| future revision | It is not intended that the first official specification include the feature. |
1.1.1 The markup language specifies that content is to be simultaneously rendered in multiple modalities (e.g. audio and video) and that output rendering is coordinated. For example, graphical output on a cellular telephone display is coordinated with spoken output.
1.2.1 The markup language specifies that content is to be simultaneously rendered in multiple modalities (e.g. audio and video) and that output rendering is uncoordinated. For example, graphical output on a cellular telephone display is uncoordinated with spoken output.
These requirements are intended to ensure that the markup language is capable of specifying cooperative dialog behavior characteristic of state-of-the-art spoken dialog systems. In general, the voice browser should compensate for its own limitations in knowledge and performance compared with equivalent human agents; for example, compensate for limitations in speech recognition capability by confirming spoken user input when necessary.
The acoustic verification may compare speech samples to an existing model (kept in some, possibly external, repository) of that speaker's voice. A verification result returns a value indicating whether the acoustic and knowledge tests were accepted or rejected. Results for verification and results for recognition may be returned simultaneously.
Note: The security administrator's interface is out-of-scope for VoiceXML.
SIV features such as enrollment and verification are voice dialogs. SIV must be compatible and complementary with other VoiceXML 3.0 dialog constructs such as speech recognition.
SIV features must be part of VoiceXML 3.0 but may not be needed in all application scenarios or implementations. Not all voice dialogs need SIV.
Some SIV processing techniques operate without using any ASR.
Some applications require the use of SIV along with other means of authentication: biometric (e.g. fingerprint, hand, retina, DNA) or non-biometric (e.g. caller ID, geolocation, personal knowledge, etc.).
SIV processing engines and network protocols (e.g. MRCP) generate events related to their operation and use. These events must be made available in a manner consistent with other VoiceXML events. Event naming structure must allow for vendor-specific and application-specific events.
These properties are provided to configure the operation of the SIV processing engines (analogous to "Generic Speech Recognition Properties" defined in VoiceXML 2.0 Section 6.3.2).
Note that this does not require EMMA in all cases, such as non-VoiceXML 3.0 environments. This also does not specify the version of EMMA.
VoiceXML 3.0 must specify the format of the result structure and version of EMMA.
This includes:
The following security aspects are out-of-charter for VoiceXML:
Enrollment is the process of collecting voice samples from a person and the subsequent generation and storage of voice reference models associated with that person.
Verification is the process of comparing an utterance against a single reference model based on a single claimed identity (e.g., user ID, account number). A verification result includes both a score and a decision.
Identification is verification with multiple identity claims. An identification result includes both the verification results for all of the individual identity claims, and the identifier of a single reference model that matches the input utterance best.
The application should have control over whether a voice model is updated
or modified based on the results of a verification.
An application developer must be able to specify at the individual turn level that one or more of the following types of processing need to be performed concurrently:
Concurrent processing of other forms of audio processing (e.g., channel detection, gender detection) should also be permitted but remain optional.
Text-prompted SIV applications require prompts to match the expected response. The application is responsible for the content of the dialog but VoiceXML is responsible for the presentation.
Many different SIV processing technologies exist. The VoiceXML 3.0 SIV architecture should avoid dependencies upon specific engine technologies.
The exact form of navigation will depend on the format and decisions around the preferred data model made by the working group. If the result is a string, string processing functions are expected to be available. If the result is an XML document, DOM or E4X-like functions are expected to be supported.
VoiceXML 3 will declare one or more mandatory result formats.
This will allow the author to prevent logging of confidential or sensitive information.
Form item recording mode (Requirements section <IP_ADDRESS> and <IP_ADDRESS>) captures media from the caller (only) during the collect phase of a dialog. Partial- and Whole-Session recording captures media from the caller, system, and/or called party (in the cases of a transferred endpoint) in a multichannel or single (mixed) channel recording. Duration of these recordings depends on the type.
Utterance recording mode is recording that occurs during an ASR or SIV form item. The audio may be endpointed, usually by the speech engine.
Session recording begins with a start command. It continues until:
Recording configuration and parameter requirements are defined in Section 2.10.2.
Restricted session recording begins with a start command and continues until:
See Table 1 for applicable controls.
This matrix specifies which features apply to which recording types.
| Feature Requirement / Recording type |
Dialog | Utterance | Session | Restricted Session |
| <IP_ADDRESS> Recording starts when caller begins speaking | Y | Y | N | N |
| <IP_ADDRESS> Initial silence interval cancels recording | Y | N | N | N |
| <IP_ADDRESS> Final silence ends recording | Y | N | N | N |
| <IP_ADDRESS> Maximum recording time | Y | N | N | N |
| <IP_ADDRESS> Terminate recording with DTMF input | Y | N | N | N |
| <IP_ADDRESS> Grammar control: modal operation | Y | N | N | N |
| <IP_ADDRESS> Media format | Y | Y | Y | Y |
| <IP_ADDRESS> Recording indicator | N | N | Y | N |
| <IP_ADDRESS> Channel assignment | N | N | Y | Y |
| <IP_ADDRESS> Channel groups | N | N | Y | Y |
| <IP_ADDRESS> Buffer control | Y | Y | N | N |
Table 1: Recording Configuration and Parameter Application
(Attributes from VoiceXML 2.0 are indicated in brackets [].)
VoiceXML 3.0 must support dynamic start-of-recording based on when a caller starts to speak
Voice Activity Detection used to determine when to initiate recording. This feature can be disabled.
VoiceXML 3.0 must support specification of an interval of silence at the beginning of the recording cycle to terminate recording [timeout].
A noinput event will be thrown if no audio is collected.
VoiceXML 3.0 must support specification of an interval of silence that indicates end of speech to terminate recording [finalsilence]
Voice Activity Detection used to determine when to stop recording. This feature can be disabled.
Finalsilence interval may be used to specify the amount of silent audio to be removed from the recording.
VoiceXML 3.0 must support specification of the maximum allowable recording time [maxtime].
VoiceXML 3.0 must provide a mechanism to control DTMF termination of an active record [dtmfterm]
VoiceXML 3.0 must enable specification of the media type of the recording [type]
Use cases:
These groups can be used to simultaneously apply other recording controls to more than one media channel (e.g. mute two channels simultaneously). Applies whether channels are in same file or in separate files (implies concept of group of channels *not* part of the same file).
A command to "start recording" must specify the details for that recording session:
The duration provided by the platform is up to the amount of audio the application requested. If that amount of audio is not available, the platform is required to provide the amount of audio that is available.
If video, repeat until un-blank.
The mechanism is platform-specific.
Recording is available for playback or upload once a recording is 'stopped'.
If a recording was stopped and uploaded, then later appended, the application will need to keep track of when to upload the new version.
Note: This does not mean all possible media types are supported on all platforms.
DEFAULT: specific to each processing type
Use cases:
DEFAULT: Tones are not removed from the recording
DEFAULT: If tone clamping is enabled, it is performed after recording has completed (not in real-time).
DEFAULT: raw
Editor's note: how to specify:Errors and events as a result of media recording must be presented to the application
Examples of types of errors possibly reported:
This does not imply platform support requirements. For example, a particular platform may support Audio Basic but not Audio Rich. Another might support Audio Rich but not all meta data elements.
TBD.
TBD.
A flow control language will be developed in conjunction with VoiceXML 3.0 (i.e. SCXML)
There must be at least one profile of VoiceXML 3.0 in which all of the following requirements are supported.
In particular, the following deferred CRs reevaluated: R51, R92, R104, R113, R145, R155, R156, R186, R230, R233, R348, R394, R528, R541, and R565.
In particular, the following unassigned CRs reevaluated: R600, R614, R619, R620, R622, R623, R624, R625, R626, R627, R628, R629, R631, and R632.
TBD
The following requirements have been satisfied by previous Voice Browser Working Group Specifications
The markup language can specify which spoken user input is interpreted by the voice browser, as well as the content rendered as spoken output by the voice browser.
Audio output: <prompt>, <audio> VoiceXML 2.0
Audio input: <grammar> SRGS 1.0
The markup language specifies that user input from multiple modalities is to be interpreted by the voice browser. There is no requirement that the input modalities are simultaneously active. For example, a voice browser interpreting the markup language in a telephony environment could accept DTMF input in one dialog state, and spoken input in another.
<grammar> mode attribute: dtmf,voice SRGS 1.0
The markup language specifies that user input from different modalities is to be interpreted at the same time. There is no requirement that interpretation of the input modalities are co-ordinated. For example, a voice browser in a desktop environment could accept keyboard input or spoken input in same dialog state.
<grammar> mode attribute: dtmf,voice SRGS 1.0
<field> defining multiple <grammar>s with different mode attribute values VoiceXML 2.0
The markup language specifies that user input from multiple modalities is interpreted at the same time and that interpretation of the inputs are co-ordinated by the voice browser. For example, in a telephony environment, the user can type200 on the keypad and say transfer to checking account and the interpretations are co-ordinated so that they are understood as transfer 200 to checking account.
<grammar> mode attribute: dtmf,voice SRGS 1.0
<field> defining multiple <grammar>s with different mode attribute values VoiceXML 2.0
The markup language specifies that content is rendered in multiple modalities by the voice browser. There is no requirement the output modalities are rendered simultaneously. For example, a voice browser could output speech in one dialog state, and graphics in another.
<prompt>, <audio> VoiceXML 2.0
The markup language specifies that content is rendered in multiple modalities at the same time. There is no requirement the rendering of output modalities are co-ordinated. For example, a voice browser in a desktop environment could display graphics and provide audio output at the same time.
<prompt>, <audio> VoiceXML 2.0
The markup language specifies that content is to be simultaneously rendered in multiple modalities and that output rendering is co-ordinated. For example, graphical output on a cellular telephone display is co-ordinated with spoken output.
<prompt>, <audio> VoiceXML 2.0
Mixed initiative refers to dialog where one participant take the
initiative by, for example, asking a question and expects the other
participant to respond to this initiative by, for example, answering the
question. The other participant, however, responds instead with an initiative
by asking another question. Typically, the first participant then responds to
this initiative, before the second participant responds to the original
initiative. This behavior is illustrated below:
S-A1: When do you want to fly to Paris?
U-B1: What did you say?
S-B2: I said when do you want to fly to Paris?
U-A2: Tuesday.
where A1 is responded to in A2 after a nested interaction, or sub-dialog in B1 and B2. Note that the B2 response itself could have been another initiative leading to further nesting of the interaction.
The form-level mixed initiative requirement is that the markup language can specify to the voice browser that it can take the initiative when user expects a response, and also allow the user to take the initiative when it expects a response where the content of these initiatives is relevant to the task at hand, contains navigation instructions or concerns general meta-communication issues. This mixed initiative requirement is particularly important when processing form input (hence the name) and is further elaborated in requirements A.2.1.1, A.2.1.2, A.2.1.3 and A.2.1.4 below.
<field> VoiceXML 2.0
<noinput>, <nomatch> VoiceXML 2.0
The markup language can specify that a clarification sub-dialog should be
performed when the user provides incomplete, form-related information. For
example, in a flight enquiry service, the departure city and date may be
required but the user does not always provide all the information at once:
S1: How can I help you?
U1: I want to fly to Paris.
S2: When?
U1: Monday
U1 is incomplete (or 'underinformative') with respect to the service (or form) and the system then initiates a sub-dialog in S2 to collect the required information. If additional parameters are required, further sub-dialogs may be initiated.
<initial>, <field> VoiceXML 2.0
The markup language can specify that a confirmation sub-dialog is to be
performed when the confidence associated with the interpretation of the user
input is too low.
U1: I want to fly to Paris.
S1: Did you say 'I want a fly to Paris'?
U2: Yes.
S2: When?
U3: ...
Note confirmation sub-dialogs take precedence over clarification sub-dialogs.
<field> VoiceXML 2.0
name$.confidence shadow variable VoiceXML 2.0
The markup language can specify that unsolicited user input in a
sub-dialog which corrects earlier input is to be interpreted appropriately.
For example, in a confirmation sub-dialog users may provide corrective
information relevant to the form:
S1: Did you say you wanted to travel from Paris?
U1: No, from Perros. (modification)
U1': Yes, from Paris (repetition)
<field> VoiceXML 2.0
$GARBAGE rule SRGS 1.0
The markup language can specify that unsolicited user input in a
sub-dialog which is not corrective but additional, relevant information for
the current form is to be interpreted appropriately. For example, in a
confirmation sub-dialog users may provide additional information relevant to
the form:
S1: Did you say you wanted to travel from Paris?
U1: Yes, I want to fly to Paris on Monday around 11.30
<initial>, <field> VoiceXML 2.0
form level <grammar>s VoiceXML 2.0, SRGS 1.0
The markup language needs to address mixed initiative in dialogs which involve more than one task (or topic). For example, a portal service may allow the user to interact with a number of specific services such as car hire, hotel reservation, flight enquiries, etc, which may be located on the different web sites or servers. This requirement is further elaborated in requirements A.2.2.1, A.2.2.2, A.2.2.3, A.2.2.4 and A.2.2.5 below.
The markup language can specify how users can explicitly switch from one task to another. For example, by means of a set of global commands which are active in all tasks and which take the user to a specific task; e.g. Take me to car hire, Go to hotel reservations.
<link>, <goto>, <submit> VoiceXML 2.0
form level <grammar>s VoiceXML 2.0, SRGS 1.0
The markup language can specify how users can implicitly switch from one task to another. For example, by means of simply uttering a phrases relevant to another task; I want to reserve a McLaren F1 in Monaco next Wednesday.
<link>, <goto>, <submit> VoiceXML 2.0
form level <grammar>s VoiceXML 2.0, SRGS 1.0
The markup language can specify how users can explicitly return to a previous task at any time. For example, by means of global task navigation commands such as previous task.
<link>, <goto> VoiceXML 2.0
The markup language can specify that users can automatically return to the previous task upon completion or explicit cancellation of the current task.
<link>, <goto> VoiceXML 2.0
The markup language can specify that when task switching occurs the previous task is suspended rather than canceled. Thus when the user returns to the previous task, the interaction is resumed at the point it was suspended.
<link> VoiceXML 2.0
The markup language can specify help information when requested by the
user. Help information should be available in all dialog states.
S1: How can I help you?
U1: What can you do?
S2: I can give you flight information about flights between major cities
world-wide just like a travel agent. How can I help you?
U1: I want a flight to Paris ...
Help information can be tapered so that it can be elaborated upon on subsequent user requests.
<help> using count attribute for tapering VoiceXML 2.0
The markup language can specify how error events generated by the voice
browser are to be handled. For example, by initiating a sub-dialog to
describe and correct the error:
S1: How can I help you?
U1: <audio but no interpretation>
S2: Sorry, I didn't understand that. Where do you want to travel to?
U2: Paris
The markup language can specify how specific types of errors encountered in spoken dialog, e.g. no audio, too loud/soft, no interpretation, no audio, internal error, etc, are to be handled as well as providing a general 'catch all' method.
<error>, <nomatch>, <noinput>, <catch> VoiceXML 2.0
The markup language can specify what to do when the voice browser times
out waiting for input; for example, a timeout event can be handled by
repeating the current dialog state:
S1: Did you say Monday?
U1: <timeout>
S2: Did you say Monday?
Note that the strategy may be dependent upon the environment; in a desktop environment, repetition for example may be irritating.
<noinput>, <catch> VoiceXML 2.0
The markup language specifies a set of meta-command functions which are available in all dialog states; for example, repeat, cancel, quit, operator, etc.
The precise set of meta-commands will be co-ordinated with the Telephony Speech Standards Committee.
The markup language should specify how the scope of meta-commands like 'cancel' is resolved.
Universal Grammars VoiceXML 2.0
The markup language specifies when the user is able to bargein on the system output, and when it is not allowed.
Note: The output device may generate timestamped events when barge-in occurs (see 3.9).
bargein property VoiceXML 2.0
The markup language specifies a mechanism to allow transfer of the caller to another line in a telephony environment. For example, in cases of dialog breakdown, the user can be transferred to an operator (cf. 'callto' in HTML). The markup language also provides a mechanism to deal with transfer failures such as when the called line is busy or engaged.
<transfer> VoiceXML 2.0
<createcall>, <redirect> CCXML 1.0
The markup language provides a mechanism to terminate the session (cf. user-terminated sessions via a 'quit' meta-command in 2.6).
Universal Grammars VoiceXML 2.0
The markup language must support a generic component interface to allow for the use of external components on the client and/or server side. The interface provides a mechanism for transferring data between the markup language's variables and the component. Examples of such data are: configuration parameters (such as timeouts), and events for data input and error codes. Except for event handling, a call to an external component does not directly change the dialog state, i.e. the dialog continues in the state from which the external component was called.
Examples of external components are pre-built dialog components and server scripts. Pre-built dialogs are further described in Section A.3.3. Server scripts can be used to interact with remote services, devices or databases.
<property> VoiceXML 2.0
<submit> namelist attribute, <submit>, <goto> query string VoiceXML 2.0
The markup language should be easy for designers to understand and author without special tools or knowledge of vendor technology or protocols (dialog design knowledge is still essential).
Form Interpretation Algorithm (FIA) VoiceXML 2.0
The markup language allows designers to rapidly develop simple dialogs without the need to worry about interactional details but also allow designers to take more control over interaction to develop complex dialogs.
Form Interpretation Algorithm (FIA) VoiceXML 2.0
The markup language complies with the requirements of the Reusable Dialog Components Subgroup.
The markup language can specify a number of pre-built dialog components. This enables one to build a library of reusable 'dialogs'. This is useful for handling both application specific input types, such as telephone numbers, credit card number, etc as well as those that are more generic, such as times, dates, numbers, etc.
<subdialog> VoiceXML 2.0
Dialogs, states, inputs and outputs can be referenced by a URI in the markup language.
<form> id attribute, form item name attribute VoiceXML 2.0
Variables can be defined and assigned values.
Variables can be scoped within namespaces: for example, state-level, dialog-level, document-level, application-level or session-level. The markup language defines the precise scope of all variables.
The markup language must specify if variables are atomic or structured.
Variables can be assigned default values. Assignment may be optional; for example, in a flight reservation form, a 'special meal' variable need not be assigned a value by the user.
Variables may be referred to in the output content of the markup language.
The precise requirements on variables may be affected by W3C work on modularity and XML schema datatypes.
<var>, <assign>, <script> VoiceXML 2.0
User input can bind one or more state variables. A single input may bind a
single variable or it may bind multiple variables in any order; for example,
the following utterances result in the same variable bindings
application.lastresult$.interpretation VoiceXML 2.0
The markup language provides an explicit event handling mechanism for specifying actions to be carried out when events are generated in a dialog state.
Event handlers can be ordered so that if multiple event handlers match the current event, only the handler with the highest ranking is executed. By default, event handler ranking is based on proximity and specificity: i.e. the handler closest in the event hierarchy with the most specific matching conditions.
Actions can be conditional upon variable assignments, as well as the type and content of events (e.g. input events specifying media, content, confidence, and so on).
Actions include: the binding of variables with information, for example, information contained in events; transition to another dialog state (including the current state).
<catch> VoiceXML 2.0
<transition> CCXML 1.0
The markup language can provide implicit event handlers which provide default handling of, for example, timeout and error events as well as handlers for situations, such as confirmation and clarification, where there is a transition to a implicit dialog state. For example, there can be a default handler for user input events such that if the recognition confidence score is below a given threshold, then the input is confirmed in a sub-dialog.
Properties of implicit event handlers (thresholds, counters, locale, etc) can be explicitly customized in the markup language.
Implicit event handlers are always overridden by explicit handlers.
Default event handlers (nomatch, noinput, error, etc...) VoiceXML 2.0
The markup language complies with the requirements developed by the Speech Synthesis Markup Subgroup for output text content and parameter settings for the output device. Requirements on multimodal output will be co-ordinated by the Multimodal Interaction Subgroup (cf. Section 1).
In addition, the markup supports the following output features (if not already defined in the Synthesis Markup):
The output device generates timestamped events including error events and progress events (output started/stopped, current position).
<audio>, <prompt> VoiceXML 2.0
<speak> and other SSML elements SSML 1.0
application.lastresult$.markname, application.lastresult$.marktime VoiceXML 2.1
The markup language allows for richer output than variable substitution in the output content. For example, natural language generation of output content.
<prompt> VoiceXML 2.0
<speak> and other SSML elements SSML 1.0
The markup language complies with the requirements developed by the Grammar Representation Subgroup for the representation of speech grammar content. Requirements on multimodal input will be co-ordinated by the Multimodal Interaction Subgroup (cf. Section 1).
The markup language can specify the activation and deactivation of multiple speech grammars. These can be user-defined, or builtin grammars (digits, date, time, money, etc).
The markup language can specify parameters for speech grammar content including timeout parameters --- maximum initial silence, maximum utterance duration, maximum within-utterance pause --- energy thresholds necessary for bargein, etc.
The input device generates timestamped events including input timeout and error events, progress events (utterance started, interference, etc), and recognition result events (including content, interpretation/variable bindings, confidence).
In addition to speech grammars, the markup language allows input content and events to be specified for DTMF and keyboard devices.
timeout, completetimeout, incompletetimeout, interdigittimeout, termtimeout properties VoiceXML 2.0
application.lastresult$.interpretation, application.lastresult$.confidence VoiceXML 2.0
application.lastresult$.markname, application.lastresult$.marktime VoiceXML 2.1
<grammar> and other elements SRGS 1.0
One key difference between contemporary event models (e.g. DOM Level 2, 'try-catch' in object-oriented programming) is whether the same event can be handled by more than one event handler within the hierarchy. The markup language must motivate whether it supports this feature or not.
For development and testing it is important that data and events are to be logged by the voice browser. At the most detailed level, this will include logging of input and output audio data. A mechanism which allows logged data to be retrieved from a voice browser, preferably via standard Internet protocol (http, ftp, etc), is also required.
One approach is to require that the markup language can control logging via, for example, an optional meta tag. Another approach is for logging to be controlled by means other than the markup language, such as via proprietary meta tags.
<log> VoiceXML 2.0
<log> CCXML 1.0


Type of Nouns
Common Nouns:
It is a name of an object in general , such as pencil, pen, paper, and so on
Proper Nouns:
It is the unique name of a person of place.


Photo Albums w/ hello.js
Demo
Provider
Albums
Photos
Get Albums from Windows
Get Albums from Facebook
Get Albums from Google
Source
Include hello.js + modules
Setup a listener
Initiate HelloJS
Plug the app keys (client_id')
Get Albums
Album button control
Get Photos
Create photo thumbnail


railo-context.Component cbvalidation.result.ValidationResult
| Property Summary | ||||
|---|---|---|---|---|
| type | property | default | serializable | required |
struct
|
constraints
The constraints evaluated in the validation process. |
true
|
false
|
|
array
|
errors
A collection of error objects represented in this result object. |
true
|
false
|
|
string
|
locale
The locale this result validation is using. |
true
|
false
|
|
any
|
resourceService
The resource bundle object. |
true
|
false
|
|
struct
|
resultMetadata
Extra metadata you can store in the results object. |
true
|
false
|
|
string
|
targetName
The name of the target object. |
true
|
false
|
| Constructor Summary | |
|---|---|
|
init([string locale=''], [string targetName=''], [any resourceService=''], [struct constraints='[runtime expression]'])
|
| Method Summary | |
|---|---|
IValidationResult
|
addError(IValidationError error)
Add errors into the result object. |
IValidationResult
|
clearErrors()
Clear All errors. |
array
|
getAllErrors([string field])
Get the Errors Array, which is an array of error messages (strings). |
string
|
getAllErrorsAsJSON([string field])
Get all errors or by field as a JSON structure. |
struct
|
getAllErrorsAsStruct([string field])
Get all errors as flat structure that can easily be used for UI display. |
string
|
getConstraints()
get: The constraints evaluated in the validation process. |
numeric
|
getErrorCount([string field])
Get how many errors you have. |
string
|
getErrors()
get: A collection of error objects represented in this result object. |
cbvalidation.result.IValidationError[]
|
getFieldErrors(string field)
Get an error object for a specific field that failed. |
string
|
getLocale()
get: The locale this result validation is using. |
string
|
getResourceService()
get: The resource bundle object. |
struct
|
getResultMetadata()
Get a collection of metadata about the validation results. |
string
|
getTargetName()
Get the name of the target object that got validated. |
string
|
getValidationLocale()
Get the validation locale. |
private void
|
globalReplacements(any message, any error)
|
boolean
|
hasErrors([string field])
Determine if the results had error or not. |
boolean
|
hasLocale()
has locale information. |
IValidationError
|
newError([struct properties])
Get a new error object. |
any
|
setConstraints(struct constraints)
set: The constraints evaluated in the validation process. |
any
|
setErrors(array errors)
set: A collection of error objects represented in this result object. |
IValidationResult
|
setLocale(string locale)
Set the validation locale. |
any
|
setResourceService(any resourceService)
set: The resource bundle object. |
IValidationResult
|
setResultMetadata(struct data)
Set a collection of metadata into the results object. |
IValidationResult
|
setTargetName(string name)
Set the validation target object name. |
| Methods inherited from class railo-context.Component |
|---|
| None |
| Constructor Detail |
|---|
locale
targetName
resourceService
constraints
| Property Detail |
|---|
The constraints evaluated in the validation process
required
- falseserializable
- trueA collection of error objects represented in this result object
required
- falseserializable
- trueThe locale this result validation is using
required
- falseserializable
- trueThe resource bundle object
required
- falseserializable
- trueExtra metadata you can store in the results object
required
- falseserializable
- trueThe name of the target object
required
- falseserializable
- true| Method Detail |
|---|
Add errors into the result object
addError
in interface
cbvalidation.models.result.IValidationResult
error
- The validation error to add into the results objectClear All errors
clearErrors
in interface
cbvalidation.models.result.IValidationResult
Get the Errors Array, which is an array of error messages (strings)
getAllErrors
in interface
cbvalidation.models.result.IValidationResult
field
- The field to use to filter the error messages on (optional)Get all errors or by field as a JSON structure
field
Get all errors as flat structure that can easily be used for UI display
field
get: The constraints evaluated in the validation process
Get how many errors you have
getErrorCount
in interface
cbvalidation.models.result.IValidationResult
field
- The field to count on (optional)get: A collection of error objects represented in this result object
Get an error object for a specific field that failed. Throws exception if the field does not exist
getFieldErrors
in interface
cbvalidation.models.result.IValidationResult
field
- The field to return error objects onget: The locale this result validation is using
get: The resource bundle object
Get a collection of metadata about the validation results
getResultMetadata
in interface
cbvalidation.models.result.IValidationResult
Get the name of the target object that got validated
getTargetName
in interface
cbvalidation.models.result.IValidationResult
Get the validation locale
getValidationLocale
in interface
cbvalidation.models.result.IValidationResult
message
error
Determine if the results had error or not
hasErrors
in interface
cbvalidation.models.result.IValidationResult
field
- The field to count on (optional)has locale information
hasLocale
in interface
cbvalidation.models.result.IValidationResult
Get a new error object
properties
set: The constraints evaluated in the validation process
constraints
set: A collection of error objects represented in this result object
errors
Set the validation locale
setLocale
in interface
cbvalidation.models.result.IValidationResult
locale
set: The resource bundle object
resourceService
Set a collection of metadata into the results object
setResultMetadata
in interface
cbvalidation.models.result.IValidationResult
data
Set the validation target object name
setTargetName
in interface
cbvalidation.models.result.IValidationResult
name


Make An App For The SensorTag. This app charts magnetometer data from the Texas Instruments SensorTag. Note that you must run this app in the Evothings client app, or build a Cordova app with the plugin com.evothings.ble. Device with support for Bluetooth 4.0 is required.
You can browse the source code for this example at the Evothings GitHub repository
The file index.html is the entry point of the app.
The file File app.js contains JavaScript code for the app that communicates with the SensorTag using BLE.
This example runs in Evothings Client on Android or iOS.
You need to run the example in the Evothings client app. Alternatively, you can make a Cordova application if you wish to distribute the app. You then need to include the Cordova plugin com.evothings.ble. See page Evothings Client for further details.
An iOS device or an Android device with support for Bluetooth 4.0 (which includes BLE) is required. For Android version 4.3 or later is needed. Please note that BLE support on Android is still not fully mature. As a result, you may experience difficulties running this example. If the app stops working, restart the Evothings client app and/or reset Bluetooth on the device.
You need the Texas Instruments SensorTag to run this example app, it sells from Texas Instruments website for 25$ and has in-all six different MEMS sensors on-board; accelerometer, gyroscope, magnetometer, IR temperature, humidity and barometric pressure (and a BLE radio of course).
Follow these steps to get started with this example:


org.apache.spark.streaming.dstream
Classes
ConstantInputDStream
DStream
DStreamCheckpointData
FileInputDStream
FilteredDStream
FlatMappedDStream
FlatMapValuedDStream
ForEachDStream
GlommedDStream
InputDStream
MapPartitionedDStream
MappedDStream
MapValuedDStream
PairDStreamFunctions
PluggableInputDStream
QueueInputDStream
RawInputDStream
RawNetworkReceiver
ReceiverInputDStream
ReducedWindowedDStream
ShuffledDStream
SocketInputDStream
SocketReceiver
StateDStream
TransformedDStream
UnionDStream
WindowedDStream


Year
Key Events
1836 - Arrival of Colonel Light in the ship the Rapid.
1836 - Adelaide Founded
1836 - Town Acres up for auction.
1874 - The University of Adelaide founded
1883 - Adelaide Zoo opens
1885 - First woman, Edith Emily Dornwell, to graduate from The University of Adelaide
1928 - Adelaide Railway completed
1986 - O-Bahn guided busway opens
1987 - Adelaide Concention Centre opens
1991 - The university of South Australia is established


Write here the labels you want to survey (comma separated):
Owner:
Repository:
OAuth token:
if debug mode is activated, app will log to help you


Loading application...
(Are the JavaScript files missing?)
(The JavaScript code needs to be compiled from the TypeScript code.)
Copyright © Project Nayuki – https://www.nayuki.io/page/qr-code-generator-library


We'll print and deliver your letter to the post office for you. Send a letter in less than 3-minutes.
We'll let you know when your letter is delivered. Register an account to track multiple letters in one place.
Our letter handlers are under strict non-disclosure agreements, and all letters are sent with protective envelopes.


Distance teaches us to appriciate the days that we are able to spend Together.
Distance teaches us the Defination of patience. Its also a reminder that every
moment Together is special and every second together should be cherished


RAII object that encapsulates the Receive operation over one chanel in an unknown transport. More...
#include <ReceiverResource.h>
Public Member Functions | |
| bool | Receive (octet *receiveBuffer, uint32_t receiveBufferCapacity, uint32_t &receiveBufferSize, Locator_t &originLocator) |
| Performs a blocking receive through the channel managed by this resource, notifying about the origin locator. More... | |
| bool | SupportsLocator (const Locator_t &localLocator) |
| Reports whether this resource supports the given local locator (i.e., said locator maps to the transport channel managed by this resource). More... | |
| void | Abort () |
| Aborts a blocking receive (thread safe). More... | |
| ReceiverResource (ReceiverResource &&) | |
| Resources can only be transfered through move semantics. More... | |
| ~ReceiverResource () | |
Friends | |
| class | NetworkFactory |
| Only NetworkFactory is ever allowed to construct a ReceiverResource from scratch. More... | |
RAII object that encapsulates the Receive operation over one chanel in an unknown transport.
A Receiver resource is always univocally associated to a transport channel; the act of constructing a Receiver Resource opens the channel and its destruction closes it.
| ReceiverResource | ( | ReceiverResource && | ) |
Resources can only be transfered through move semantics.
Copy, assignment, and construction outside of the factory are forbidden.
| ~ReceiverResource | ( | ) |
| void Abort | ( | ) |
Aborts a blocking receive (thread safe).
| bool Receive | ( | octet * | receiveBuffer, |
| uint32_t | receiveBufferCapacity, | ||
| uint32_t & | receiveBufferSize, | ||
| Locator_t & | originLocator | ||
| ) |
Performs a blocking receive through the channel managed by this resource, notifying about the origin locator.
| receiveBuffer | Pointer to a buffer where to store the received message. | |
| receiveBufferCapacity | Capacity of the reception buffer. Will be used as a boundary check for the previous parameter. | |
| [out] | receiveBufferSize | Final size of the received message. |
| [out] | originLocator | Address of the remote sender. |
| bool SupportsLocator | ( | const Locator_t & | localLocator | ) |
Reports whether this resource supports the given local locator (i.e., said locator maps to the transport channel managed by this resource).
|
friend |
Only NetworkFactory is ever allowed to construct a ReceiverResource from scratch.
In doing so, it guarantees the transport and channel are in a valid state for this resource to exist.


|
C++ Actor Framework 0.19
|
Describes a listener to the subscription that will receive an event whenever the observer calls request
or cancel
.
More...
#include <subscription.hpp>
Public Member Functions | |
| virtual void | on_request (coordinated *sink, size_t n)=0 |
| virtual void | on_cancel (coordinated *sink)=0 |
| Public Member Functions inherited from caf::flow::coordinated | |
| virtual void | ref_coordinated () const noexcept=0 |
| Increases the reference count of the coordinated. | |
| virtual void | deref_coordinated () const noexcept=0 |
| Decreases the reference count of the coordinated and destroys the object if necessary. | |
Describes a listener to the subscription that will receive an event whenever the observer calls request
or cancel
.


for line in $(cat file | grep -v '^ *#')
do
echo "Line: $line"
done
grep -v '^ *#' < file | while IFS= read -r line
do
echo "Line: $line"
done
or without a subshell (bash, zsh, ksh):
while IFS= read -r line
do
echo "Line: $line"
done < <(grep -v '^ *#' < file)
or without a subshell, with a pipe (more portable, but write a file on the filesystem):
mkfifo mypipe
grep -v '^ *#' < file > mypipe &
while IFS= read -r line
do
echo "Line: $line"
done < mypipe
rm mypipe
For loops by default (subject to $IFS
) read word by word. Additionally, glob expansion will occur.
Given this text file:
foo *
bar
The for loop will print:
Line: foo
Line: aardwark.jpg
Line: bullfrog.jpg
...
The while loop will print:
Line: foo *
Line: bar
If you do want to read word by word, you can set $IFS
appropriately and disable globbing with set -f
, and then [[ignore]] this warning. Alternatively, you can pipe through tr ' ' '\n'
to turn words into lines, and then use while read
. In Bash/Ksh, you can also use a while read -a
loop to get an array of words per line.


Going the Distance Endurance
By Ross Anthony
Though, called a non-fiction feature by it's producer, "Endurance" is loosely a documentary on Haile Gebrselassie ... Ethiopia's Olympic gold winner and one of the world's greatest distance runners.
Yonas Zergaw (Haile's real life nephew) plays the young Haile, growing up on a ranching farm in Ethiopia. The eighth of ten children, the young Haile must run six miles to school and still get home in time to milk the cows and harvest the wheat. Some of Haile's real life family are present in the film (though at times standing in for younger or dead relatives). Their recreations are surprisingly genuine.
"Endurance" spares us the intrusion of a narrator, preferring to let the simple images tell the story in their own time. The music ... wonderfully wide open and rich (like the landscape) in the beginning, thins out during the breadth of the distance. It embraces elements of the indigenous music, but certainly not exclusively.
This sweetly simple and honest documentary, shouldn't be confused with a feature film; but crossing the finish line, Haile's sincerity, will no doubt choke up a tear in your eye.
Starring Haile Gebrselassie and his family. Written and directed by Leslie Woodhead. Produced by Edward R. Pressman, Terrence Malick and Max Palevsky at Disney. Rated G.
Grade..........................B
-- Copyright © 1999 Ross Anthony, currently based in Los Angeles, has scripted and shot documentaries, music videos, and shorts in 35 countries across North America, Europe, Africa and Asia. For more reviews visit: http://RossAnthony.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


| PostgreSQL 9.5.19 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 37. Event Triggers | Next |
Thanks to the table_rewrite event, it is possible to implement a table rewriting policy only allowing the rewrite in maintenance windows.
Here's an example implementing such a policy.
CREATE OR REPLACE FUNCTION no_rewrite() RETURNS event_trigger LANGUAGE plpgsql AS $$ --- --- Implement local Table Rewriting policy: --- public.foo is not allowed rewriting, ever --- other tables are only allowed rewriting between 1am and 6am --- unless they have more than 100 blocks --- DECLARE table_oid oid := pg_event_trigger_table_rewrite_oid(); current_hour integer := extract('hour' from current_time); pages integer; max_pages integer := 100; BEGIN IF pg_event_trigger_table_rewrite_oid() = 'public.foo'::regclass THEN RAISE EXCEPTION 'you''re not allowed to rewrite the table %', table_oid::regclass; END IF; SELECT INTO pages relpages FROM pg_class WHERE oid = table_oid; IF pages > max_pages THEN RAISE EXCEPTION 'rewrites only allowed for table with less than % pages', max_pages; END IF; IF current_hour NOT BETWEEN 1 AND 6 THEN RAISE EXCEPTION 'rewrites only allowed between 1am and 6am'; END IF; END; $$; CREATE EVENT TRIGGER no_rewrite_allowed ON table_rewrite EXECUTE PROCEDURE no_rewrite();


The year is... way too many.
Humanity and the others out there have littered everything with their technology and their junk in general. Now even space is clogged.
One day the universe decided it has had enough of it and wants to build something new.
But for that it needs space. More space in space. Which is a bit weird...
Anyway...
The universe asked you, personally, for help. It scattered black holes here and there, they already cleaned up a good chunk of the mess but they need a hand with the rest.


{eval
$icons = array(
0 => '{lang poke_0}',
1 => '
{lang poke_1}',
2 => ' {lang poke_2}',
3 => ' {lang poke_3}',
4 => ' {lang poke_4}',
5 => ' {lang poke_5}',
6 => ' {lang poke_6}',
7 => ' {lang poke_7}',
8 => ' {lang poke_8}',
9 => ' {lang poke_9}',
10 => ' {lang poke_10}',
11 => ' {lang poke_11}',
12 => ' {lang poke_12}',
13 => ' {lang poke_13}'
);
}


--- layout: default ---
Custom rebranding package are based on your specific needs. Let us capture your brand’s voice so your message is clear for your target audience! We offer the following services through rebranding. Don’t see what you need? Give us a shout and we can help you find it.
Let us build you a custom package!We will define your brand, identify your target, and perform and in depth analysis of your business. We’ll pinpoint the specific social media platforms you should be using, as well as relevant, personalized strategies to increase your following, engagement, and your revenue. As part of each strategy session, you’ll receive an in-depth website and branding analysis from a professional web designer/development team with over ten years of professional experience. We will also create a custom plan for your team to implement our recommended strategy. If you need a game plan for your business and want to learn about all things marketing and social media, we highly recommend a strategy session.
Instagram is powerful. If you’re looking to reach millennials (amongst other target markets) and make your brand stand out, we offer private and small group Instagram for Small Business courses, both virtual and in person. Each course is about an hour in length and teaches you the steps you need to grow your business on Instagram. Courses are conducted in a private group on Facebook Live, in the comfort of your own home. In person classes also available in the Austin area upon request.
On a tighter budget? We meet for a quick power hour to give you the most relevant strategies to identify your target and help you grow digitally. It’s like a mini Brand Strategy Session! Available the first Sunday of each month, limited spots available.
Personal branding for those involved in direct sales is a very unique type of marketing from those of a traditional ecommerce, brick and mortar business, or other service. In this session, we’ll dive into personal branding and how you can differentiate yourself amongst the sea of other consultants. We’ll talk about which platforms to be on, what content to post, and what sets you apart from the crowd to create your own personal brand that your direct sales business will organically weave into.
Are you a social media influencer who is looking to have a bank of beautiful, social ready content? Our professional Social Media Photographers style, shoot, and edit content for your feed to help you create a cohesive message for your audience. Each session guarantees at least 100 digital images for your use.
We offer gorgeous flat lay, product, and lifestyle shots for your branding and social media.


Release Notes
NUnit 2.5 Final Release - Version <IP_ADDRESS>22 - May 2, 2009
General
- NUnit now uses a new version numbering scheme. The first three
dot-separated values represent the release level, as before, while
the fourth is a build number tied to the date of the release.
- This release includes pNUnit, an extended NUnit runner for distributed
parallel tests. The pNUnit program was developed at Codice Software
for use in testing the Plastic SCM and has been contributed to NUnit.
For more info about using pNUnit see the
pNUnit site.
- The installer now offers Typical, Complete and Custom options. Selecting
Typical gets you the NUnit framework, core, console runner and Gui.
To install pNUnit or the NUnit tests select Complete or Custom.
- There are no longer separate distributed packages for .NET 1.1 and 2.0.
Both the binary zip and msi packages contain subdirectories for .NET
1.1 and 2.0. The Gui is now built for .NET 2.0 only. Tests may still
be run under .NET 1.0 o 1.1 by running in a separate process.
In the case of the msi, the user may elect to install either
or both of them.
- The Visual Studio solutions and projects are now in a directory tree that
is parallel to the source tree. A VS2008 project has been added and the
VS2003 project was removed. Certain components are still built for .NET
1.0 and 1.1 through the NAnt script.
- Most of the code for Assert and for elements of the constraint
syntax is now generated. This allows us to more rapidly deploy new
constraints with their corresponding syntax. The file SyntaxElements.txt
contains the specifications used in generating the code and the source of
a tool for generating the source is included in the tools directory. The
generated files continue to reside in the NUnit source at this time,
so that those working in other areas of the code don't have to regenerate
them each time they make changes.
- The nunit.framework.extensions and nunit.core.extensions assemblies have
been removed from the build.
- NUnit is now built using NAnt 0.86 beta 1. The windows installer is created
with WiX 2.0.5085
Framework - Attributes
- NUnit 2.5 features parameterized tests, which are defined using a number
of new attributes:
- TestCaseAttribute allows the programmer to
specify the arguments and a number of optional parameters inline.
- TestCaseSourceAttribute identifies a property, field or method
that to provide the arguments and other parameters.
- ValuesAttribute is used on a method parameter to specify
a set of values to be supplied as arguments inline.
- RangeAttribute works like ValuesAttribute but lets
you specify a range to be used for the arguments.
- RandomAttribute works like ValuesAttribute but lets
you use random values for the arguments.
- ValueSourceAttribute is placed on a method paramter to
specify the property, field or method that will supply arguments.
- CombinatorialAttribute, PairwiseAttribute and
SequentialAttribute indicate how data supplied for
individual parameters is combined to form test cases. The default
is Combinatorial, which supplies all possible combinations.
- The presence of either TestCaseAttribute or TestCaseSourceAttribute
on a method is now sufficient to identify it as a test even if it is not
decorated with TestAttribute.
- Test Cases specified using TestCaseAttribute or TestCaseSourceAttribute
may include a Description, ExpectedException, Categories and Properties in
addition to the arguments themselves.
- Parameterized test methods may be generic. NUnit will deduce
the correct implementation to use based on the types of the
parameters provided. Generic test methods are supported in
both generic and non-generic clases.
- NUnit now includes an implementation of Theories, similar to what
is found in JUnit. Support for Theories is provided by the
Theory, Datapoint and Datapoints attributes and by
the Assume.That method. For more information and further links,
see the TheoryAttribute
documentation page.
- Other new attributes provided in NUnit 2.5 are:
- RequiresThreadAttribute forces creation of a new thread and
may optionally indicate the desired ApartmentState for the thread.
- RequiresSTAAttribute causes the test to run in the STA. A
new thread is created only if the parent is not in the STA. On
methods, the .NET-provided STAThreadAttribute may also be used.
- RequiresMTAAttribute causes the test to run in the MTA. A
new thread is created only if the parent is not in the MTA. On
methods, the .NET-provided MTAThreadAttribute may also be used.
- TimeoutAttribute is used to set the timeout for tests. When
used on classes or assemblies, the timeout value is used as the
default timeout for all subordinate test cases. Test cases with
a timeout value run on a separate thread and return a failure
message if the timeout is exceeded.
- The MaxTimeAttribute specifies a miximum elapsed time for a
test case. If the test takes longer, it is reported as a failure.
This attribute was previously available as an extension.
Unlike TimeoutAttribute, MaxTimeAttribute
does not cause the test to be cancelled, but merely times it.
- RepeatAttribute causes a test case to be executed multiple
times. This attribute was previously available as an extension.
- RequiredAddinAttribute may be used to mark an assembly,
indicating the name of any addin that is required to run the tests. If the
addin is not present, the test assembly is marked NotRunnable.
- TestFixture classes may now be generic. They must be marked with
one or more instances of TextFixtureAttribute using the new
constructor that takes an array of Types. NUnit will instantiate
the fixture multiple times, using the type arguments provided.
- Use of the TestFixtureAttribute is now optional in designating
non-generic classes that contain tests marked with either
TestAttribute or TestCaseAttribute.
- More than one method may now be marked with the SetUp, TearDown,
TestFixtureSetUp and TestFixtureTearDown attributes. Setups
in a base class are executed before those in a derived class and teardowns
are executed in the reverse order. If there are multiple setups or teardowns
defined at the same level, the order is unspecified so this practice is
not generally recommended.
- PropertyAttribute has been modified internally to use a dictionary
of name/value pairs rather than just a single name and value. This feature
is not exposed for direct use, but may be accessed by derived attributes
that want to apply multiple named values to the test. For a simple
example of usage, see the code for RequiredThreadAttribute.
- PlatformAttribute has been extended to accept the new keywords
NT6, Vista and Win2008Server.
- The MessageMatch enum used with ExpectedExceptionAttribute
has been extended with a new value StartsWith, indicating that the
exception message must start with the string provided.
- TestCaseAttribute now supports a MessageMatch
property.
Framework - Constraints
- New constraints and corresponding syntactic constructs are provided:
- Is.InRange tests that a value lies within a specified range.
- Has.Attribute() tests for the presence of a specified attribute
on a type and optionally applies further tests to that attribute.
- Is.InstanceOf replaces Is.InstanceOfType, which
is now deprecated.
- Is.AssignableTo allows reversing the operands of AssignableFrom
for increased clarity in the code and in any error messages when the
actual value is of the derived type.
- Throws.Exception allows testing the exception thrown by a
delegate in place and provides the ability to make arbitrary tests
on the caught exception. Throws.TypeOf() and Throws.InstanceOf()
are provided as shorthand for the commonly used Throws.Exception.TypeOf()
and Throws.Exception.InstanceOf.
- Throws.Nothing provides for testing that a delegate does
not throw. While it doesn't do much, it serves the purpose of
converting an unexpected error into a test failure.
- Is.Ordered allows testing a collection is ordered according
to a supplied comparison criterion. (contributed by Simone Busoli)
- Is.SamePath(string) tests that two paths are equivalent, without
requiring that they exist in the file system.
- Is.SamePathOrUnder(string) tests that one path is under another,
without requiring that either path exists in the file system.
- DelayedConstraint and the After syntactic element allow
delaying the application of a constraint until a certain time has passed.
See DelayedConstraint for
features and limitations.
- The parsing of constraint expressions written using the fluent interface
has been reorganized internally, with the following benefits:
- Meaningless sequences like "...Null.Null..." or "...And.Or..."
will no longer compile - the NUnit tests actually verify this
by attempting to compile them.
- Syntax modifiers like Within and IgnoreCase are
now only accepted - and shown by intellisense - on constraints that
actually make use of them.
- New And and Or infix operators are provided.
- The With provides some ability to group constraints.
- The "syntax helper" classes, Is, Has, Text,
List and Throws, have been moved to the NUnit.Framework
namespace, so that they may be used more easily.
- PropertyConstraint now works with Types when testing for the
existence of a named property.
- EqualConstraint has been enhanced with
several new modifiers, which may be used immediately after
the Within(...) modifier to indicate how a numeric tolerance value
should be interpreted.
- Ulps = as units in the last place (floating point only)
- Percent = as a percentage of expected value
- Days = as a TimeSpan in days
- Hours = as a TimeSpan in hours
- Minutes = as a TimeSpan in minutes
- Seconds = as a TimeSpan in seconds
- Milliseconds = as a TimeSpan in milliseconds
- Ticks = as a TimeSpan in ticks
- The comparison constraints (GreaterThan, LessThan, etc.),
RangeConstraint and CollectionOrderedConstraint may now be used
with objects that implement IComparable<T>.
- The syntax used for specifying that a collection is ordered has changed.
Is.Ordered is now a property. The property name to use for ordering
is specified using Is.Ordered.By(name).
- The following constraints now accept a Using modifier to indicate
that a user-specified comparer should be used:
- EqualConstraint
- GreaterThanConstraint
- GreaterThanOrEqualConstraint
- LessThanConstraint
- LessThanOrEqualConstraint
- RangeConstraint
- UniqueItemsConstraint
- CollectionContainsConstraint
- CollectionEquivalentConstraint
- CollectionSubsetConstraint
- CollectionOrderedConstraint
The provided comparer may be any of the following:
- IComparer
- IComparer<T>
- Comparison<T>
In addition, EqualConstraint may use:
- IEqualityComparer
- IEqualityComparer<T>
Using C# 3.0, lambda expressions are also accepted.
- A new syntax element, Matches(Constraint), allows use of
custom constraints, predicates or lambda expressions in constraint expressions.
Framework - Asserts
- New Assert methods:
- Assert.IsOrdered allows checking that a collection is in
a particular order. (contributed by Simone Busoli)
- The DirectoryAssert class provides tests on directories:
- AreEqual(DirectoryInfo, DirectoryInfo)
- AreEqual(string, string)
- AreNotEqual(DirectoryInfo, DirectoryInfo)
- AreNotEqual(string, string)
- IsEmpty(DirectoryInfo, DirectoryInfo)
- IsEmpty(string, string)
- IsNotEmpty(DirectoryInfo, DirectoryInfo)
- IsNotEmpty(string, string)
- IsWithin(DirectoryInfo, DirectoryInfo)
- IsWithin(string, string)
- IsNotWithin(DirectoryInfo, DirectoryInfo)
- IsNotWithin(string, string)
- Assert.Throws(Type expectedException, TestDelegate code)
gives more control over tests of expected exceptions.
TestDelegate is a delegate, which may of course be supplied
as an anonymous delegate or lambda expression. If the correct exception
type is thrown, the actual exception is returned from the method, so
that further verification may be performed.
- Assert.Throws(Constraint, TestDelegate) allows passing a
constraint or constraint expression as the first argument, which
is then applied to the resulting exception.
- Assert.DoesNotThrow method tests that a
delegate does not throw an exception.
- Assert.Pass allows early termination of a test with a
successful result.
- Assert.Inconclusive terminates a test, returning
the new Inconclusive result state.
- Assert.That has been extended to allow a delegate or a reference
as the argument. By default, these are evaluated before being used by
the constraint supplied but some constraints may delay evaluation. The
new DelayedConstraint is an example.
- AssertionHelper has been updated so that the Expect overloads now
include the signatures newly introduced for Assert.That.
- NUnit now includes added functionality in the .NET 2.0 build of
the framework. The following additional features are supported:
- All Asserts and Constraints work with nullable types.
- Some Asserts allow an alternate generic syntax for convenience:
- Assert.IsInstanceOf<T>(object actual);
- Assert.IsNotInstanceOf<T>(object actual);
- Assert.IsAssignableFrom<T>(object actual);
- Assert.IsNotAssignableFrom<T>(object actual);
- Assert.Throws<T>(TypeSnippet code);
Framework - Miscellaneous
- The following obsolete interfaces, classes and methods have been removed:
- The IAsserter interface
- The AbstractAsserter class
- The Assertion class
- The AssertionFailureMessage class
- The old NUnit.Framework.TestCase class used for inheriting test classes
- The Assert.DoAssert() method
- Two ExpectedExceptionAttribute(Type, string) constructor
- Two ExpectedExceptionAttribute(string, string) constructor
Core
- NUnit now supports running tests in a separate process or in
multiple processes per assembly. In addition, tests run in
a separate process may use a different runtime framework
from that under which NUnit is running.
Note: In the Beta release, execution of tests under Mono
from a copy of NUnit that is running under .NET is not yet supported.
- NUnit now allows use of static methods as tests and for SetUp, TearDown,
TestFixtureSetUp and TestFixtureTearDown.
- Failures and Errors are now distinquished internally and in summary reports.
Methods that are not run because they are invalid are also reported separately.
- NUnit 2.5 is able to recognize, load and run NUnitLite tests.
Console
- The console runner now supports a /framework option, which
allows running the tests under a different version of the CLR.
- The new /process:xxxxx command line option is used to run
tests in a separate process or in multiple processes per assembly.
- A new commandline option, /timeout:nnnn allows you to specify a
default timeout value, which is applied to each test case in the run without
a Timeout specified.
- The summary report now displays Errors, Failures, Inconclusive, Ignored and Skipped tests
separately. More detailed information on non-runnable tests and setup failures
is provided.
- The console summary report is no longer created using a stylesheet, which
renders the /transform option meaningless. The option has been removed.
Gui
- The Gui is now able to display the source code for test or production
code from the stack trace, provided the assemblies contain source code
information and the source code is available. Contributed by Irénée Hottier.
- Reloading the tests after changing settings in a way that modifies
the shape of the tree is now handled correctly.
- The Settings Dialog now opens to the page that was last viewed.
- The default gui display now uses a single tab for all text output. For
users upgrading from an earlier release, the current settings are
honored. If you wish to change to the new default, use the Restore Defaults
button on the Text Output settings dialog.
- The tree display shows non-runnable tests in red and inconclusive tests
in orange. Inconclusive tests are temporarily listed
on the Tests Not Run tab for this release.
- The final test run display shows a more detailed summary: passed tests,
errors, failures, inconclusive, non-runnable, skipped and ignored.
- The Project Editor now allows setting the ProcessModel and
DomainUsage for a project to control how that project is
loaded and run. It also supports setting a target runtime
framework for each configuration. If the target runtime is
different from the runtime under which NUnit is running, the
tests will be run automatically in a separate process under
the target runtime.
- The TestLoader settings dialog provides default settings for
running tests in a separate process or in multiple processes
if not specified in the NUnit project file.
- The Project Editor no longer reloads the tests as each
individual change is made. Tests are reloaded after the
editor is closed and only if changes have been made to
the overall project configuration or to the active
configuration.
- The Addin Dialog now shows an error message for any addin that
fails to load. (from 2.4.8)
- The Assembly Info display now uses a scrolling text box and has
been enhanced to show information about the Process and AppDomain
in which the test is running. It also shows two runtime versions for
eachtest assembly: the one for which it was built and the one under
which it is currently loaded.
- The status bar now displays errors and failures separately.
- Properties with a collection for a value are now displayed
displayed as a comma-separated list in the properties window.
Extensibility
- The implementation of constraints has been simplified so that it is now
possible to provide modifier properties on a constraint without creating
any additional classes. Such custom constraints can be integrated into
the NUnit syntax by rebuilding the framework assembly.
Note: The ability to create new syntactic
elements without rebuilding the framework is planned for a future release.
- A simpler method of providing new data point extensions based
on attributes applied to the parameter itself is now available.
Such attributes may be derived from ValuesAttribute and
do not require any special addin in order to work.
- New extension points TestCaseProviders and DataPointProviders
allows addins to provide data for parameterized tests.
- The following extensions are included in the nunit.core.extensions
and nunit.framework.extensions assemblies:
- The XmlConstraint extension, which allows comparing two xml files
Bug Fixes
- Loading a single assembly and then adding another assembly using
the Add Assembly menu item was not working correctly.
- Reloading tests after settings changes was failing when the
new settings changed the shape of the tree in such a way
that the new tests didn't match the old ones correctly.
- The Reload Project menu item was followed by a prompt asking
if the current project state should be saved first and making
the reload work in an unexpected way if you answered yes.
- A class without a TestFixture attribute, containing only
TestCase methods, without any Tests, was not recognized as
a test fixture.
- Assert.DoesNotThrow was failing to display a user message.
- Xml documentation for Assert.IsNotEmpty and Assert.AreEqual
was incorrect.
- CollectionAssert.AreEqual and EqualConstraint were not
working with IEnumerables that were not also Collections.
- PlatformAttribute now distinguishes correctly between
Vista and Windows 2008 Server.
- The Gui output panes were failing to use a fixed font. (from 2.4.8)
- NUnit tests of AssertThrows were not working on systems using
non-English cultures.
- Domains were not unloading correctly in some circumstances. Unloading
is now done on a separate thread.
- An NUnitSettings.xml file of zero length was causing a crash. (from 2.4.8)
- Invoking the gui with /exclude:XXX, where XXX is a non-existent
category, was causing all tests to be excluded. (from 2.4.8)
- Categories were not working properly on repeated tests. (from 2.4.8)
- A serious memory leak was fixed in the NUnit test runners. (from 2.4.8)
- Static SetUp and TearDown methods were not being called in a SetUpFixture.
- The current directory used when executing addins that load tests was
not correctly set.
Earlier Releases


EXPERIENCE:
January 2013 - May 2014
Research Assistant to William Leap
American Univeristy, Washington, DC
- Performed extensive research on topics related to linguistic anthropology in the US in order to provide historical evidence for Leap’s most recent manuscript.
- Identified and gathered relevant materials from collections at the Library of Congress, the American Folklife Center, and the National Archives
- Synthesized archival data, information from police department records, court opinions, military documents, early gay-liberation era publications to produce arguments regarding the validity of Leap’s theoretical writing
- Wrote historical overviews of archival data to be included in Leap’s manuscript
February 2013 - Present
Producer, Documentary Film: “Housing Difference”
Independent Production, Washington, DC
- Researched, edited and distributed short, nonprofit documentary film (still in production) which seeks to educate a general audience about the deleterious effects of displacement and housing-related inequalities particularly the tensions these issues create within and between DC’s communities. (View trailer)
- Daily monitoring of local events related to housing and development
- Contacted, built relationships with, and interviewed a variety of individuals connected to or affected by housing-related inequalities, including scholars, community activists, and tenants.
- Management of budget and equipment costs
May 2012 - August 2012
Assistant Director
Mentors of Minorities in Education (MOMIES TLC) ‘Safe Haven Summer Camp’, Washington, DC
- Worked as part of a four-person team responsible for planning and managing summer enrichment program with emphasis on cultural empowerment and social justice for 50-60 students aged 5-14
- Lead a team of four counselors and tutors with which I directed lesson planning, assisted in classroom activities and conflict resolution
- Independently researched and planned more than 10 field trips, while keeping costs affordable for all campers and their families
- Formed relationships with MOMIES TLC families as I managed camp payments, financial aid, field trip finances, pick-ups and drop offs, and involved parents in classroom activities
September 2011 - January 2012
Intern
Woodhull Sexual Freedom Alliance, Washington, DC
- Worked as an assistant to the executive director on a variety of projects and administrative tasks, including maintenance of donor relationships through Constant Contact and E-Tapestry
- Established and developed Woodhull’s social media presence through Facebook, Twitter, Hootsuite and Pinterest
- Met with representatives of grassroots groups to develop coalition building strategies around common issues
- Created preliminary strategic plan for Woodhull’s “Family Matters” video campaign that seeks to raise awareness of the issues faced by co-parenting, single parent, and other nontraditional families
EDUCATION:
September 2010 - May 2014
American University, Washington, DC
GPA: 3.83
B.A., American Studies,
Cum Laude
Multidisciplinary program including courses in anthropology, sociology, history, literature. Additional anthropology classes taken outside of major at the graduate level.
March 2013
Matthais Student Research Conference
Selected to present paper: “Hate Crimes, Gentrification, Covert Racism and Belonging in Logan Circle”
March 2012
Queer Alternative Spring Break
Traveled to San Francisco with a group of eleven students to work with homeless LGBT youth, volunteered with variety of community groups and organizations, studied the networks of support services that seek to address the unique needs of homeless queer youth.


[§269E-13] Excavation permits. Prior to conducting an excavation, the excavator shall obtain all necessary permits from the appropriate agency or agencies pursuant to the laws, rules, regulations, procedures, and requirements governing the issuance of such permits. [L 2004, c 141, pt of §1]


rror
is a package to make using classed conditions in R easier. It contains utilities for creating, raising, and catching conditions including but not limited to messages, warnings, and errors. It is built on top of the base condition handling system, and is fully compatible with it.
rror
is not on CRAN yet, but can be installed from GitHub with
# install.packages("remotes") remotes::install_github("alistaire47/rror")
Conditions are a formalized way of providing feedback to the user and handling runtime issues. In most languages, conditions include errors and warnings; in R, messages (usually generated with message()
, equivalent to warning()
or stop()
) are also conditions, used for generating diagnostic messages for the user.
R also has infrastructure to create, raise, and handle conditions of your own creation, which may or may not inherit from one of the built-in conditions.
rror
?The condition handling system of R is very powerful, but unfortunately most users don’t take advantage of its full power, because it is not trivial to understand, a process further hindered by limited documentation.
rror
makes it very simple to leverage more of the power of this system—in particular working with classed errors. For instance, if a package maintainer is validating arguments and wants to raise an error for bad input, instead of generating a simpleError
from stop()
, e.g.
plus1 <- function(x) { if (!is.numeric(x)) { stop("`x` must be numeric") } x + 1 } plus1(2) #> [1] 3 tryCatch( plus1("a"), error = function(e) str(e) ) #> List of 2 #> $ message: chr "`x` must be numeric" #> $ call : language plus1("a") #> - attr(*, "class")= chr [1:3] "simpleError" "error" "condition"
the maintainer can raise a classed error, e.g.
plus2 <- function(x){ if (!is.numeric(x)) { rror::raise(rror::error_condition("`x` must be numeric", class = "value_error")) } x + 2 } plus2(3) #> [1] 5 rror::except( plus2("b"), value_error = function(e) str(e) # we can catch specific error classes! ) #> List of 2 #> $ message: chr "`x` must be numeric" #> $ call : language plus2(x = "b") #> - attr(*, "capture_call")= logi TRUE #> - attr(*, "class")= chr [1:3] "value_error" "error" "condition"
Common conditions can be predefined and reused.
rror
’s condition handling function, except()
, also has some benefits over tryCatch()
. In particular, because the handlers registered in tryCatch()
are exiting handlers, it is not very useful for suppressing repeated warnings or messages and continuing:
f1 <- function(i) warning("warning ", i) tryCatch( { for (i in 1:3) f1(i) 2 + 2 }, warning = function(w) print(w) ) #> <simpleWarning in f1(i): warning 1>
except()
handles errors with exiting handlers, but non-fatal conditions use local handlers, which lets specific errors be easily suppressed:
f2 <- function(i) { rror::raise( rror::warning_condition( paste("warning", i), class = "number_warning" ) ) } rror::except( { for (i in 1:3) f2(i) 2 + 2 }, number_warning = function(w) print(w) ) #> <number_warning in f2(i = i): warning 1> #> <number_warning in f2(i = i): warning 2> #> <number_warning in f2(i = i): warning 3> #> [1] 4


{% extends "layout.html" %} {% set notificationHtml %} {% if basketLimitState == "below-limit" %}
If you want to request a document for a different company, you will need to search for the company on the register. In the company's filing history, select 'Request document' for the document you require.
{% else %}You cannot add more than {{ basketLimit }} items to your order. To add more, you'll need to remove some items first.
{% endif %} {% endset %} {% block pageTitle %} Request a document - GOV.UK {% endblock %} {% block beforeContent %} {{ govukBackLink({ text: "Back", href: "/company/" + companyNumber + "/filing-history" }) }} {% endblock %} {% block content %} {% if basketLimitState == "display-limit-error" %} {{ govukErrorSummary({ titleText: ERROR_SUMMARY_TITLE, errorList: [ { text: "Your basket is full. To add more to your order, you'll need to remove some items first.", href: basketWebUrl } ] }) }} {% else %} {{ govukNotificationBanner({ html: notificationHtml }) }} {% endif %}Use this service to ask us to add a document to a company's filing history if it is not currently available.
It can take us several hours to check the availability of a document. We will aim to add it to a company's filing history that day if the request is received between 8:30am and 3pm, Monday to Friday (excluding bank holidays).
If you make a request after 3pm, we will add the document the next working day.
After you have made the request, you can check the company's filing history for updates on the document's availability.
Requesting a document takes around 5 minutes.
{{ govukButton({ text: "Start now", href: startNowUrl, classes: "govuk-!-margin-top-2 govuk-!-margin-bottom-8", isStartButton: true, disabled: basketLimitState == 'display-limit-error', attributes: { "data-event-id": "start-now-button", onclick: "_paq.push(['trackGoal'," + MISSING_IMAGE_DELIVERY_PIWIK_START_GOAL_ID + "]);" } }) }}It costs £3 to request a document. If we cannot add the document to the filing history we will contact you to issue a refund.
You can pay by debit or credit card. You cannot pay using a Companies House account.


Back
Does the defendant have anything valuable?
If Mary Richards has assets that could be sold at auction, such as a vehicle or jewellery, it could help you recover your money.
If Mary Richards has assets that could be sold at auction, such as a vehicle or jewellery, it could help you recover your money.