Etikettarkiv: geek

Unix Complete

Unix CompleteMan älskar je referensverk…uppenbarligen. Det här är ytterligare en av de där bra att ha böckerna som man måste ha i bokhyllan när jag känner en obetvingad lust att datornörda loss bara för att. Som med Linux Command Summary. Nu har jag använt Linux så länge att det kan anses vara mitt go-to-OS men eftersom jag inte nördar ner mig i olika datorrelaterade proejct så ofta längre så kan jag antagligen egentligen mer om det som finns under motorhuven på operativsystem som BeOS, OS/2, eComStation, Windows NT-varianterna et cetera så jag behöver fortfarande läsa upp mig på dokumentationen när jag behöver finjustera förgasarna i systemet. Då är det alltid skönt att ha lite referensverk. Nu är det här ett Unix-relaterat verk men Linux är ju ett derivat därav. Jag tror inte att jag någonsin kommit längre än att ha installerat SUN Solaris (numera Oracle Solaris) och använt det max i några dagar till någon vecka Kanske till och med att jag installerat FreeBSD någon gång under sekelskiftet (vilket av dem får ni själva fundera ut). Efter att ha testat en mängd olika system, även en VAX Station har stått på mitt skrivbord, så har det ändå blivit så att jag fastnat för ett system som inte vet hur man sviker sin husse, även om husse aldrig riktigt lär sig hur kugghjulen snurrar under huven. När husse är så lat så måste husse ha bra referenslitteratur så att han vet vad han skall göra när en blinkande prompt möter hans öga. Bläddrar i den ibland men den får väl anses som just en sådan där bra att ha bok. No more no less.

Tankar om Afrikas mobilmarknad

Kenya - HarambeeLäser två intressanta artiklar på Business Daily om mobil-marknaden i Kenya, och för all del i Sydafrika och framför allt artikeln om hur stor del av den totala summa pengar som mobila start-ups i Afrika lyckades eska ihop under 2017. Sydafrika får ihop en tredjedel av den totala summan av pendar som olika mobila start-ups lyckats få investerat i sina projekt i hela det sub-sahariska området, men sedan kommer Nairobi, den kenyanska huvudstaden på andra plats med 25% av totalen. Som jag tidigare avslöjat så ser jag Östafrika som det kanske intressantaste området när det gäller kombinationen och mötet av finans och teknik i världen just nu. De behov som människor har här kräver otroligt mycket av de utvecklare av tjänster som nu slåss om marknaderna. Det är extremt intressant att följa. Den kommande explosionen i Vstarfrika som kommer att följa i kölvattnet på detta är också värd att böra hålla ögonen på. Artikeln Kenya firms up innovation hub status with Sh14bn deals ger en liten inblick om inte annat. Intressant att notera är att högriskmarknaden i Sydafrika faktiskt drar till sig mest investerade $ i området. Sydafrika som är på väg att införa fullskalig socialism efter samma modell som Zimbabwe med svält, elände folkförföljelse och etnisk rensning som följd. Det kommer innebära en enorm risk för inveseterare. Visserligen kan det också bli så att Sydafrika stannar vid den etniska utrensningen och efter att ha gjord sig av med den Afrikandiska ursprungsbefolkningen anser sig vara färdig med sin frihetsprocess och sedan slår på bromsen på socialistrelaterdt våld. Men fan tro’t!
Nästa artikel av intresse är Airtel eats into Safaricom, Telkom Kenya’s market om hur Airtel har börjat ta marknadsandelar av Safaricom och Telcom Kenya. Det är härligt att se hur de tre stora operatörerna strider med erbjudanden till kunderna. Sund härlig markndsekonomi i sin prydnad. Striden mellan olika mobila betalsystemen kommer definitivt vara en av de avgörande striderna som sätter marknaden för flera år framåt. Kommer T-kash ta marknad av M-Pesa? Det blir en viktig fråga.

Linux Command Summary (Clarica Grove & Phil Hughes)

Linux Command SummaryLinux Command Summary är ett rent referensverk och används som sådant också. Den hittade nog in i mitt bibliotek redan vid tiden för millenieskiftet och användes nog när jag experimenterade med någon dåtida Mandrake Linux distribution (någonstans från version 8.2 till 9.0). Nu har den börjat användas igen efter att endast ha stått och samlat damm genom åren. Visserligen har jag använt mig av uteslutande Linux för mitt dagliga datorbehov och en del OS/2 och eComStation för hobby och lek sedan jag stängde ner min egen webbserver och flyttade till ett webbhotell igen. Boken är en samling av kommandon för Linux och olika växlar och attribut för dessa. Den här boken kommer att komma till heders igen nu när jag har installerat Damn Small Linux på en gammal Compaq laptop men målsättningen att verkligen lära mig hur man plockar ihop en egen personlig men högst användbar Linux-distro med bara de programvaror som jag använder och kanske lyckas slimma ner en installation med bara de drivrutiner man behöver för just den aktuella hårdvaran och med de senaste versionerna av de mjukvaror jag använder för tillfället, jag menar, t.o.m. med Damn Small Linux så ger en färdig hårddiskinstallation en miljö med minst fyra ordbeandlare/texteditorer. Det finns alltid möjlighet att cutomizera en installation och den här testmiljön ger förutsättningar för det samtidigt som Linux Command Summary blir ett helt nödvändigt verktyg för att kunna använda Linux fullt ut. Boken kommer att bli vältummad framöver och som jag bruka betona så är referenslitteratur minst lika viktigt (om inte den viktigaste litteraturen) i bokhyllan som skönlitteratur per se.

Backyard Computing – 2018

* ARMADA 1500c C366 * * COMPAQ *
Celeron 366MHz

中古ノートパソコン販売 ARMADA 1500c C366 COMPAQ

画像をクリックすると大きい画像がご覧になれます
<メーカー> COMPAQ
<型番> ARMADA 1500c C366
<状態>
<発売日> 1999/09
<定価>\200,000
納期:- / 数量:-
-&nbsp(税込/div>
売切れ送料
ランク※ ランク:
Windows 98搭載ノートパソコンです。
メモリを32MB増設し、合計64MBです。PCカードスロットのダミーカードが欠品しております。
中古2
付属品 アダプタ、電源ケーブル、リカバリディスク、取扱説明書の4点です。
OS Windows 98 Office
CPU Celeron 366MHz ディスプレイ 12.1インチ 800×600 (SVGA)
メモリ 64MB カードスロット PCカード*2
ハードディスク 4GB インターフェース / / USB*2
光学ドライブ CD 重量 3.1kg
ネットワーク / – サイズ
参考URL

http://www.mobile-mania.jp/htmls/4948382079466-9.html

Roadtrip – Hässleholm

Brown Sugar

Utan bil sedan September ifjol så nu när det hamnat en Alfa Romeo i min ägo igen så kliade det i kroppen att komma iväg och göra något som jag varit förhindrad att företa mig sedan Toyotan slogs sönder. Nu skulle jag äntligen ta mig ner till Hässleholm igen. LeStrange och jag hade gjort ett litet byte med en baskropp mot gamla laptops. Tanken var att jag skulle få bort mitt kli i fingrarna och få igång en skön lekdator igen. Stora gamla och tunga bärbara datorer som kostar mer att skicka postledes än vad de är värda i ett byte mot en baskropp laddad med mickar men inget mer. Inte värt att skicka så det var bara att försöa vänta ut ett tillfälle när någon skulle ta sig i någon riktning till eller från Hässleholm – Stockholm. Dessutom så hade LeStrange några prylar som skulle plockas upp på Twang i Stockholm på vägen så nu när jag hade en ny italiensk skönhet till förfogande så var det dags att testa den på en ordentlig roadtrip.

Jag slutade mitt arbetspass klockan 11:00 men hade fått information av LeStrange att det inte skulle vara öppen innan klockan 13:00 så jag hängde kvar på jobbet en stund ectra. Det var ju lika bra att försöka få tag på de gitarrer och laptops som skulle ner till LeStranges verkstad nu när jag äntligen skulle komma iväg.
Väl inne på Södermalm hade jag strax lastat bilen och sedan var det bara att rulla iväg mot Skåne. Första tankstoppet i Sillekrog, en klassiker är ju alltid en klassiker. Sedan var det bara att plugga in hörlurarna i öronen och lyssna på podcasts hela vägen söderut.

McDonalds Värnamo

Strax efter att jag hade passerat Jönköping och den outsägliga sträckningen genom Småland hade börjat passera under mina däck så började jag känna att jag inte hade ätit något under dagen. Nu när det var eftermiddag och blodsockret hade lämnat kroppen så började jag nästan bli skakig av hungern. Så jag ville ha en snabb lösning. Genom två regnskurar beslutade jag mig för att stanna vid avfarten till Värnamo och ta en hamburgare på McDonalds.
Det är märkligt att man aldrig lär sig ändå. Man vet ju redan att det kommer att ta längre tid och vara sämre service på McDonalds än gången innan man var där. Det är ju ett sluttande plan och särskilt när jag var så hungrig som jag var. Jag svor över att jag inte valde konkurrenten Burger King som låg mer eller mindre vägg i vägg. Man lurar sig ständigt på att McDonalds förr i tiden hade en policy att servera gästerna snabbt men att det är så länge sedan att det faktiskt inte finns någon anledning att besöka dem längre. Eftersom både Burger King och MAX har mer välsmakande hamburgare så är det ju meningslöst att återvända till Donken. Dessutom undrar man ju hur inkompetenta de kan bli. Lägga upp pommesen på brickan tio tolv minuter innan de serverar den, det är inte de spänstigaste potatisstavarna man får serverat direkt. Riktigt degenererat skräpställe nu för tiden. Omsprungna av samtliga konkurrenter.

Den legendariska workshopen på Järnvägsgatan i HässleholmVäl framme på Järnvägsgatan i Hässleholm så blev det häng i LeStranges legendariska workshop och det hänger alltid något udda och kul i verkstaden. Nu hängde det en Burns Bison kopia som fångade mitt öga längs väggen. Mycket cool och habegäret slog i taket naturligtvis. Tyvärr var den behäftad med en del halsproblematik annars hade den fått följa med mig hem. Basismen hade fått en nytändning med den grunkan. Det kan jag lova. Vilken bastard! Vilken underbar skapelse!

Efter lite häng i verkstaden och lite kläm-&-känn på mina nya laptops så dök till sist Freddan upp och vi gav oss ut på stan och gungade runt i Brown Sugar, ligans Low Rider med mullrande V8. En Cadillac är alltid en Cadillac och denna -79:a var inget undantag. Vi gungade runt i Hässleholm med slagskeppet ett tag, glidande runt i byn, innan vi åkte tillbaka till verkstaden.
Det blev några timmars surr nere i verkstaden innan vi gav oss. Diskussioner om Skåne vs. Sverige, om politik och frihet och valet i höst. Vi pratade om allt möjligt och strax efter klockan tre på natten så var det dags att bege sig hemåt. Jag hade kunnat tacka ja till LeStranges erbjudande om att sova på soffan men jag ville ut på vägearna och kände mig tillräckligt pigg för att kunna åka hem igen. Det var ärligt talat att bedra sig själv en hel del. Jag var långt ifrån pigg och redan i höjd med Värnamo började jag fundera på att stanna till och sova en stund i bilen. Det blev att stålsätta sig och efter att ha tankat både bilen och mig själv (Unleash The Beast!) i Ödeshög så var det bara att stå på.

Det fick bli ett par bensträckare och fler burkar Monster innan jag äntligen kunde rulla in min Alfa Romeo hemma på farmen någon gång efter klockan 10 på förmiddagen.
Nästa gång sover jag kvar på LeStranges soffa i verkstaden för jag var alldeles för trött på vägen hem för att kunna njuta av bilturen och jag sov sedan bort hela lördagen i alla fall. Hade lika gärna kunnat tillbringa en halv lördag i verkstaden och klämt loss på den där Burns-kopian.

Hemma igen. Det innebar cirka 1150 kilometer (715 miles) och till min glädje så har bilen rullat troget och krångelfritt hela vägen. Nice!

Första stoppet, på Twang på Katarina Bangata

Första stoppet, på Twang på Katarina Bangata

På väg

Tankstopp i Sillekrog

Brahehus

Cadillac - Brown Sugar

Cadillac - Brown Sugar

Cadillac - Brown Sugar

Fuel for the Driver

Ge mig flera möjligheter

Det finns visserligen trådlösa tangentbord till smartphones via bluetooth men vad jag verkligen saknar är något slags dockningsstation som de gamla laptop-lösningarna som jag exempelvis körde på min gamla IBM ThinkPad 600 eller min Compaq LTE 5280 då man bara anslöt sin bärbara dator till dockningsstationen så hade man all kringutrustning på plats och kunde läsa vad Mae Ling Mak har för sig för tillfället. Visst jag kan se att de flesta skulle tycka att det kanske vore något till en surfplatta men inget för en smartphone men där är jag av helt motsatt åsikt. Är det något jag saknar för att utnyttja telefonen maximalt och för att kunna verkligen utnyttja dess kapacitet maximalt är just möjligheten att använda den som den enda enhet jag behöver släpa på.
En dockningsstation med anslutningar för tengentbord och externa diskar allt med USB-anslutning naturligtvis. Så är det bara att plugga in och jobba på. De enda programvaror jag använder idag som jag inte kan utföra på min mobiltelefon är ildredigering i GIMP och Raw Therapee. Det var några år sedan jag gjorde någon ljudredigering men det skulle också bli svårt att pilla med på en liten skärm men i övrigt finns möjligheten att få ut ett normaltsnabbt skrivande med ett fullstort tangentbord så ge mig vad jag vill ha så jag kan använda min smartphone maximalt!

XOS3 - Hummingbird

Nästan lika nördig som förr (The Geek Comeback?)

När jag satt och försökte hitta vidare information om hur jag skall komma vidare med min gamla Python-kod, i första steget uppgradera den så att den är 3.0 kompatibel och i andra steget få den att köra på min telefon som en app, så hamande jag ganska omgående hos en tillverkare som inte ens fanns listade på GSMARENA.com, nämligen Infinix. Infinix har redan på sin första sida en länk för att ladda ner Open Source-kod. Efter en snabb titt på deras hemsida så inser jag att de verkligen försöker knyta användarna närmare och bli en del av utvecklingsprocessen av produkterna. Mycket lovvärt och jag tänker hålla ett öga på Infinix och särskilt deras användarforum och deras öppna källkod och om det är något jag kan komma vidare med. Nu är ju min enkla Python-kod närmas att anse som inbecillt simplistisk men den har ju ett extremt specifikt syfte och den är tänkt att vara mobil från början så varför inte? Det skall bli intressant var jag landar. Om det fungerar med Python hela vägen, eller om jag kommer behöva använda JAVA eller kanske någon variant av XML eller rent av en HTML-lösning?
Nu har jag dessutom hittat den utomordentligt trevliga programmeringsmiljön Ninja-IDE som känns skön att jobba med Python-koden med i.

Infinix XClub

VoxML (Voice Markup Language)

Speech ApplicationsDen här sajten startade ju som en tekniksajt en gång i tiden och jag tänkte att jag skulle få upp lite av det material som fanns här då. Det är många år sedan och de flesta tekniker är idag hopplöst obsoleta men det är lite kul att ha dem på plats här i alla fall så jag börjar med att lägga upp en liten genomgång av VoxML (Voice Markup Language) av vilken den senaste versionen mig veterligen ar 1.1 som kom 1999.VoxML var ett initiativ från Motorola som ett tag konkurrerade med VoiceXML om att kunna leverera röststyrda telefonapplikationer över webben. VoiceXML vann dock kampen då allt fler företag anslöt till VoiceXML och gjorde sina röster hörda för att göra detta till en standard.

VoxML, lika väl som JSML, är dock värt att känna till när man håller på att utveckla webbapplikationer för röststyrning.

Till skillnad från HTML så som har en tvådimensionell layout så har VoxML bara en dimension i sin layout, nämligen tid.
I VoxML sker allting perspektivet tid.
I HTML visas i sidor, i VoxML är motsvarigheten dialoger som delas upp i mindre enheter kallade steps.

VoxML baseras på eXtensile Markup Language (XML) och följer XMLs syntax-regler. För mer information om VoxMLs struktur i jämförelse med XML så titta nätmare på VoxMLs DTD.

Är du sugen på att titta närmare på hur VoxML ser ut och fungerar så bärjar vår guide här.

De två viktigaste elementen i VoxML är DIALOG och STEP. De är elementen som
skapar grundstrukturen i en VoxMLapplikation.

Elementet DIALOG kan närmast jämföras med BODY-elementet i HTML, alla andra element
existerar inom DIALOG-elementet.

STEP-elementet anger de olika stegen i applikationen.
STEP är de delmoment inom DIALOG-elementet som du navigerar
igenom med de kommandon som du anger.

Vi tittar på ett exempel, exempel01.vml:

<?xml version=”1.0″?>
<DIALOG>
<STEP NAME=”init”>
  <PROMPT>Please select a soft drink.</Prompt>
  <HELP> Your choises are coke, pepsi, 7 up or root beer</HELP>
  <INPUT TYPE=”OPTIONLIST” NAME=”drink” NEXT=”#confirm”>
    <OPTION VALUE=”coke”> coke </OPTION>
    <OPTION VALUE=”pepsi”> pepsi </OPTION>
    <OPTION VALUE=”7 up”> 7 up </OPTION>
    <OPTION VALUE=”root beer”> root beer </OPTION>
  </INPUT>
</STEP>

<STEP NAME=”confirm”>
  <PROMPT> You orded <VALUE NAME=”drink”/>.</PROMPT>
</STEP>
</DIALOG>

När en VoxML-applikation anropas initieras den det STEP-element som heter ”init”, användaren
kommer då att höra innehållet i PROMPT-elementet.
Om användaren anger att han vill ha hjälp innan han gör ett val så kommer innehållet i HELP-elementet att läsas upp.
När användaren gör ett val kommer browsern att exekvera STEP-elementet
som heter ”confirm” som helt enkelt läser upp det gjorda valet och sedan avslutar
applikationen.

Det är ett par intressanta detaljer som är värda att notera när vi tittar på exemplet ovan.
Den första raden i koden består av XML-deklarationen, som måste vara första
raden i alla VoxML-dokument.

Dessutom så kan det vara på sin plats att påpeka att STEP-elementen utförs i den ordning de anropas
och alltså inte nödvändigtvis i den ordning de förekommer i koden.

De element som förekommer i exemplet ovan, DIALOG, STEP, PROMPT, HELP och INPUT, är de som förekommer
oftast i VoxML och man bör känna sig ordentligt bekant med dessa element innan man går vidare med
mindre ofta förekommande element.

ACK

Ibland kan det vara nödvändigt att dubbel-kontrollera information som användaren har givit.
Detta skulle man som utvecklare kunna lösa genom att skapa ytterligare en STEP-sekvens som läser
upp det användaren angivit och frågar om detta är korrekt.
ACK-elementet (acknowledge) erbjuder en enklare lösning på detta problem.

Ett ACK-element måste befinna sig inom ett STEP- eller CLASS-element.

SYNTAX

<ACK [CONFIRM=”value” [REPROMPT=”value”]]>
   text
</ACK>

ATTRIBUT

Attributnamn

Tillåtna värden

CONFIRM

YORN (default)

REPROMPT

Y
N (default)

EXEMPEL

<STEP NAME=”card_type”>
    <PROMPT>
    What type of credit card do you have?
    </PROMPT>
     INPUT NAME=”type” TYPE=”OPTIONLIST” NEXT=”#exp_date”>
      <OPTION VALUE=”visa”>visa</OPTION>
      <OPTION VALUE=”mc”>mastercard</OPTION>
      <OPTION VALUE=”discover”>discover</OPTION>
    </INPUT>
    <ACK CONFIRM=”YORN” REPROMPT=”Y”>
      I thought you said <VALUE NAME=”type”/>
      <BREAK/> I that correct?
    </ACK>
</STEP>

I det här exemplet används ACK-elementet för att konfirmera användarens val av kreditkort.

När den här koden tolkas av VoxMLs röst-browser kommer den att läsa texten från PROMPT-elementet med hjälp av text-till-tal teknik,
vänta på användarens respons (visa, mastercard eller discover) och sedan be användaren att konfirmera om
valet av kontokort.

Om användaren svarar ”yes” kommer browsern att fortsätta till STEP-elementet som heter ”exp”.
Om användaren svarar ”no”, kommer PROMPT-elementets text läsas igen och användaren får på nytt en möjlighet
att göra sitt val.

Browsern går tillbaks till STEP-elementet och börjar så att säga om från början.

Confirm-attributet specificerar vilken typ av ”input field” som förväntas av användaren.
YORN (yes or no) är lierad med en inbyggd taligenkänningsgrammatik som tillåter alla typer av positiv och negativ respons istället för ett enkelt yes eller no.

REPROMPT-attributet specificerar vad som skall göras om konfimationen falerar.
Om REPROMPT är satt till ”Y” kommer användaren att dirigeras till PROMPT igen.
Om det är satt till ”N” så görs inte detta.

AUDIO

AUDIO-elementet specificerar en ljudfil som skall spelas upp.

AUDIO-elementet kan användas som ett alternativ var som helst där du kan läsa text för användaren.

Ett AUDIO-element kan placeras inom ett PROMPT, EMP, PROS, HELP, ERROR, CANCEL eller ACK-element, där du kan placera text som skall läsas upp för användaren.

SYNTAX

<AUDIO SRC=”value”/>

ATTRIBUT

Attributnamn

Tillåtna värden

SRC

URL till ljudfil

EXEMPEL

<PROMPT>
      At the tone, the time will be 11:59 p m
      <AUDIO SRC=”http://localhost/sounds/beep.wav”/>
</PROMPT>

Koden ovan är ett enkelt exempel på en ljudfil inkluderad i ett PROMPT-element.

När VoxMLs Voice Browser tolkar koden kommer den att tala texten från rad två med hjälp av text-till-tal teknik och sedan spela upp WAV-filen ”beep.wav” angiven i rad tre.

BREAK

BREAK-elementet kan användas överallt där applikationen läser text eller spelar upp en ljudfil för användaren.

BREAK kan användas inom följande element: PROMPT, EMP, PROS, HELP, ERROR, CANCEL och ACK.

SYNTAX

<BREAK [MSECS=”value” | SIZE=”value”]/>

ATTRIBUT

Attributnamn

Tillåtna värden

MSECS

miliseconds (integer)

SIZE

NONE
SMALL
MEDIUM (default)
LARGE

EXEMPEL 1

<PROMPT>
      Welcome to Earth. <BREAK MSECS=”250″/>
      How may I help you?
</PROMPT>

Det första exemplet med BREAK-elementet med MSECS-attributet inom PROMPT-elementet.
När detta tolkas av browsern talar den texten ”Welcome to Earth”, göra pause i 250 millisekunder
och sedan säga ”may I help you?”.

Ett alternativ till att ange exakt antal millisekunder med MSECS-attributet kan man använda SIZE-attributet för att kontrollera längden
på pausen, som i exempel 2:

EXEMPEL 2

<PROMPT>
      Welcome to Earth. <BREAK SIZE=”MEDIUM”/>
      How may I help you?
</PROMPT>

Den exakta längden på ”SMALL”, ”MEDIUM” och ”LARGE” är definerade av systemet och kan därför ändras i kommande specifikationer av
VoxML
.

Använd MSECS-attributet om du vill ha full kontroll över längden på pausen.

CANCEL

CANCEL-elementet används av utvecklaren för att kunna erbjuda användaren att avbryta den aktuella PROMPT:en.

Om du som utvecklare inte definerar CANCEL-elementets beteende så kommer systemets förinställda beteende att användas.
Det förvalda beteendet för CANCEL-elementet är att stoppa den aktuella PROMPT:en och sedan fortsätta med nästa interaktiva INPUT.

CANCEL-elementet (precis som HELP) kan utföras av användaren genom ett flertal fraser.
”Cancel” och ”I would like to cancel, please” ger samma resultat.

CANCEL-elementet används inom STEP- eller CLASS-elementen.

SYNTAX

<CANCEL NEXT=”value” [NEXTMETHOD=”value”]/>
eller
<CANCEL NEXT=”value” [NEXTMETHOD=”value”]>text</CANCEL>

ATTRIBUT

Attributnamn

Tillåtna värden

NEXT

URL till nästa STEP eller DIALOG

NEXTMETHOD

GET (default)
POST

EXEMPEL

<STEP NAME=”report”>
    <CANCEL NEXT=”#traffic_menu”/>
    <PROMPT>Traffic conditions for Chicago, Illinois, Monday, May 18.
        Heavy congestion on..
    </PROMPT>
    <INPUT TYPE=”OPTIONLIST”>
      <OPTION NEXT=”#report”>repeat</OPTION>
      <OPTION NEXT=”#choose”>new city</OPTION>
    </INPUT>
</STEP>

Linje två i koden ovan visar hur man använder CANCEL-elementet för att specificera vad som skall hända
när användaren säger ”cancel”.
I det här fallet skall applikationen fortsätta med STEP-elementet som heter ”#traffic-menu” istället för att använda systemets förvaldavärde, vilket
hade stoppat PROMPT:en och sedan väntat på användarens nästa kommando.

Användaren kan dessutom stoppa en pågående PROMPT genom att ange ett korrekt OPTION.
I det här exemplet skulle användaren kunna avbryta PROMPT:en och fortsätta med ett annat val genom
att säga ”new city”.

CASE

CASE-elementet används för att styra beteendet på applikationen baserat på värdena på interna VoxML variabler.

CASE-elementet kan användas inom SWITCH-elementet, eller INPUT-elementet, om denna innehåller ett värde (DATE, DIGITS, MONEY, PHONE, TIME och YORN).

SYNTAX

<CASE VALUE=”value” NEXT=”value” [NEXTMETHOD=”value”]/>

ATTRIBUT

Attributnamn

Tillåtna värden

VALUE

literal value

NEXT

URL till nästa STEP eller DIALOG

EXEMPEL

<SWITCH FIELD=”piza”>
    <CASE VALUE=”pepperoni” NEXT=”#p_pizza”/>
    <CASE VALUE=”sausage” NEXT=”#s_pizza”/>
    <CASE VALUE=”veggie” NEXT=”#v_pizza”/>
</SWITCH>

Koden på linje två till fyra i exemplet ovan visar bruket av CASE-elementet inom SWITCH-elementet.

I det här exemplet används CASE-elementet för att dirigera browsern till olika STEP-element baserat på olika värden på variabeln ”pizza”.

Många VoxML-element användar attributen NEXT och NEXTMETHOD.
Dessa specificerar STEP-elementet att gå till nästa genom att använda standardiserade HTTP-konventioner.

Om du vill flytta till ett STEP-element inom det aktuella VoxML-dokumentet använder du ”#step_name” notationen.

Om du vill flytta till ett annat VoxML-dokument sätter du värdet på NEXT-attributet till
den URL som representerar det dokumentet och du kan också ange HTTP-metoden som skall användas för att tillgå dokumentet.

CLASS

CLASS-elementet definerar en uppsättning element som kan återanvändas inom DIALOG.

SYNTAX

<CLASS NAME=”value” [PARENT=”value”][BARGEIN=”value”][COST=”value”]>
VoxML
</CLASS>

ATTRIBUT

Attributnamn

Tillåtna värden

NAME

Namnet på klassen(identifier)

PARENT

Namnet på super-klassen(identifier)

BARGEIN

Y (default) – tillåter användaren att ”barge-in” för att stoppa prompt
N

COST

”kostnaden” för att exekvera varje STEG som tillhör klassen.
(COST-attributet är en plattforms-beroende del av VoxML. En viss browser-implementation kan välja att använda sådana delar)

EXAMPLES

<CLASS NAME=”simple”>
    <HELP> Your choices are <OPTIONS/> </HELP>
    <ERROR> I did not understand what you said.
      Valid resonses are <OPTIONS/> </ERROR>
</CLASS>

<STEP NAME=”beverage” PARENT=”simple”>
    <PROMPT>Please choose a drink.</PROMPT>
    <INPUT NAME=”drink” TYPE=”OPTIONLIST”>
      <OPTION NEXT=”#food”>coke</OPTION>
      <OPTION NEXT=”#food”>pepsi</OPTION>
    </INPUT>
</STEP>

<STEP NAME=”food” PARENT=”simple”>
    <PROMPT>Please choose a meal.</PROMPT>
    <INPUT NAME=”meal” TYPE=”OPTIONLIST”>
      <OPTION NEXT=”#deliver”>pizza</OPTION>
      <OPTION NEXT=”#deliver”>tacos</OPTION>
    </INPUT>
</STEP>

Koden på rad 1-5 illustrerar användningen av CLASS-elementet för att definera ett HELP-element och ett ERROR-element som skall användas
i flera STEP-element inom DIALOG-elementet.

Koden på rad 7-15 visar användningen av PARENT-attributet i STEP-elementetsomrefererar till CLASS-elementet och därför ärver beteendet som defineras där.

När browsern tolkar detta så kommer STEP-elementet bete sig som om HELP och ERROR-elementen var definerade exklusivt i varje STEP-element.

ARV

En klass subelement och attribut ärvs av dess subklasseroch steps, om de inte överskrids längre ner i hierarkin.
Arv är inte logiskt i vissa subelement, här följer reglerna.

COST
”Kostnaden” av ett steg har endast mening för en viss plattform som kör VoxML.
VoxML-browsern kommeratt summera den samanlagda kostnaden av de genomgångna STEP-elementen som användaren går igenom under sessionen.
Sedan skriver den ut en ”nota” TILL ANVÄNDAREN.

”Kostnaden” för ett STEP är detsamma som värdet tillägnat dess COST-attribut.
Om det inte finns ett COST-element så ärvs ”kostnaden” från dess ”parent” CLASS.

Om parent CLASS inte har en associerad COST så fortsätter ”arvsökandet” uppåt i hierarkin.

Om inget STEP eller någon av dess superklasser har ett COST-attribut så sätts ”kostnaden” att avsluta steget till noll.

BARGEIN

Detta attribut styr om användaren kan stoppa TTS-motorn genom att tala eller inte.
Här fungerar det precis som med COST, så om ett STEP inte definerar BARGEIN undersöks dess parent CLASS.

CANCEL

Se COST.

HELP

HELP fungerar lite annorlunda eftersom arvet av information är beroende av ORDINAL-attributet.

Detta betyder att om ett STEP-element har ett HELP med ORDINAL=”7″ så kommer det inte att ärva HELP ORDINAL=”7″från sin klass, men det kommer att ärva HELP med andra ORDINAL-värden.

ERROR

Arvet basers på både ORDINAL-värde och TYPE-värde.

DIALOG

DIALOG-elementet är naturligtvis fundamentalt för VoxML.

Om man skulle ställa upp ett VoxML-dokument som en trädstruktur så skulle DIALOG-elementet vara trädets rot.

DIALOG-elementet definerar den grundläggande enheten inom ett VoxML-dokument.
Oftast så finns det ett DIALOG-element per URL.

Varje DIALOG måste innehålla exakt ett STEP-element som heter ”init”.
Exekveringen av en VoxML-applikation startar med STEP-elementet som heter ”init”.

Ett DIALOG-element kan inte finnas inom någont annat VoxML-element.

SYNTAX

<DIALOG [BARGEIN=”value”]>VoxML</DIALOG>

ATTRIBUT

Attributnamn

Tillåtna värden

BARGEIN

Y (default)
N

EXEMPEL

<DIALOG>
    <STEP NAME=”init”>
      <PROMPT> Welcome to VoxML. </PROMPT>
    </STEP>
</DIALOG>

Koden ovan visr en enkel men dock fullständig VoxML DIALOG.

DIALOG-elementet specificeras på rad ett till fem och innehåller ett enkelt STEP-element som heter ”init”.
STEP-elementet innehåller ett PROMPT-element som kommer att läsas via text-to-speech.

Eftersom inget INPUT-element defineras inom STEP-elementet så kommer applikationen termineras genast efter att PROMPT-elementet har lästs upp.

EMP

EMP-elementet (emphasis) används för att markera ett område av text vilken nivå av emfasskall vara annorlunda än övrig text.

EMP-elementet kan användas överallt där text skall läsas för användaren och kan nästlas.

EMP-elementet kan befinna sig inom PROMPT, PROS, HELP, ERROR, CANCEL och ACK-elementen.

SYNTAX

<EMP [LEVEL=”value”]>text </EMP>

ATTRIBUT

Attributnamn

Tillåtna värden

LEVEL

NONE
REDUCED
MODERATE (default)
STRONG

EXAMPLES

<PROMPT>
    The weather today is going to be
    <EMP LEVEL=”strong”> really</EMP>
    bad. Up to 36 inches of snow will fall…….
</PROMPT>

Koden ovan är i stort sett självförklarande.

Den verkliga effekten av EMP-elementetbestäms av den text-to-speech (TTS) mjukvara som används av browsern.
Eftersom olika TTS-mjukvaror används (exempelvis i telefoner kontra desktop-datorer) i ett nätverks-system så kommer effekten att variera.

För att uppnå en specifik emfas-effekt skall du använda PROS-elementet istället för EMP-elementet.

Error

ERROR-elementet tillåter utvecklaren att definera hur en VoxML-applikation skall respondera på ett fel.

Om utvecklaren inte definerar en åtgärd så kommer default-värdet att användas.
Default-beteendet för ERROR-elementet är att säga frasen:
    ”An error has occurred”,
stanna kvar i aktuellt STEP-element, åter utföra PROMPT-elementet och invänta användarens respons.

ERROR-elementet kan användas inom STEP- eller CLASS-elementet.

Ett givet ERRROR-element används till alla typer av fel om man inte specificerar typen, eller till endast en specifik typ av fel.
Default används ERROR till alla typer av fel,
De feltyper som uppkommer är följande:

NOMATCH

Språkigenkänningen uppfattar ett talat ljud men kan inte med tillräckligt stor säkerhet identifiera ljudet som ett i dess grammatik förekommande fras.

NOSPEECH

Språkigenkänningen har ej uppfattat att någonting har uttalats inom föregiven tid.

TOOLITTLE

Uppstår när systemet samlar in data från ett INPUT-element av typen ”DIGITS” och färre digits än angivits var insamlat.

TOOMUCH

Uppstår när systemet samlar in data från ett INPUT-element av typen ”DIGITS” och fler digits än angivits var insamlat.

NOAUTH

När systemet försöker samla in användarinformation som användaren valt att ej ange.

NSF

????????????????????????

BADNEXT

När systemet misslyckas att hitta och visa en URL som är angiven i ett NEXT-attribut.

SYNTAX

<ERROR [TYPE=”value”] [ORDINAL=”value”] [REPROMPT=”value”] [NEXT=”value”[NEXTMETHOD=”value”]]>
    text
</ERROR>

ATTRIBUT

Attributnamn

Tillåtna värden

TYPE ALL (default)
NOMATCH
NOSPEECH
TOOLITTLE
TOOMUCH
NOAUTH
NSF
BADNEXT
ORDINAL heltal
REPROMPT Y
N (default)
NEXT URL till nästa STEP eller DIALOG
NEXTMETHOD GET (default)
POST

EXAMPLES

<STEP NAME=”errors”>
    <ERROR TYPE=”NOMATCH”> First error message.
      I did not understand what you said.</ERROR>
    <ERROR TYPE=”NOMATCH” ORDINAL=”2″>
      Second error message.
      I did not understand what you said.</ERROR>
    <PROMPT> This step tests error messages.

      Say ‘oops’ twice. Then say ‘done’ to
      choose another test.</PROMPT>
    <INPUT TYPE=”OPTIONLIST”>
      <OPTION NEXT=”#end”>done</OPTION>
    </INPUT>
</STEP>

Koden ovan illustrerar användandet av ERROR-elementet för att definera applikationens beteende inför ett fel.

På linje två defineras felmeddelandet som skall användas första gången ett fel av typen NOMATCH inträffar i STEP-elementet.

ORDINAL-attributet bestämmer vilket meddelande som skall användas om upprepade fel upstår inom samma STEP-element.

VoxML-browsern väljer ett felmeddelande baserat på en enkel algoritm:
Om felet har uppstått tre gånger så kommer browsern att leta efter ett ERROR-element med ett ORDINAL-attribut med värdet ”3”.
Om det inte finns ett sånt ERROR-element så letar browsern efter ett ERROR-element med ett ORDINAL med ”2” och sedan ”1”, för att till slut leta efter ett ERROR-element utan definerat ORDINAL.

Så om vi i exemplat ovan hade definerat ett ERROR-element med ett ORDINAL-attribut med ett värde på ”6” inom STEP-elementet och samma fel uppstått sex gånger i rad, skulle användaren höra det första felmeddelandet en gång, det andra felmeddelandet fyra gånger och slutligen felmeddelandet med ORDINAL ”6”.

HELP

HELP-elementet hjälper utvecklaren att definera applikationens beteende om användaren frågar efter hjälp.
Om applikationen inte definerar HELP-beteende för ett givet STEP-element så kommer systemets default-värde att användas.

HELP-elementet, i likhet med CANCEL-elementet, kan aktiveras med en rad olika fraser.
Användaren kan lika gärna säga ”help” som ”I would like help, please” för att aktivera beteendet.

Systemets default-inställning för HELP-elementet är att stoppa aktuellt PROMPT-element, spela upp frasen ”No help is available”, stanna kvar i aktuell STEP och köra den interaktiva INPUT som finns tillgänglig.

Help-elementet kan placeras inom STEP- och CLASS-elementen.

SYNTAX

<HELP
    [ORDINAL=”value”]
    [REPROMPT=”value”]
    [NEXT=”value” [NEXTMETHOD=”value”] ]>
      text
</HELP>

ATTRIBUT

Attributnamn

Tillåtna värden

ORDINAL

heltal

REPROMPT

Y
N (default)

NEXT

URL till nästa STEP eller DIALOG

NEXTMETHOD

GET (deault)
POST

EXEMPEL

<STEP NAME=”helps”>
    <HELP REPROMPT=”Y”>First help message.
      You should hear the prompt again. </HELP>
    <HELP ORDINAL=”2″> Second help message.
      You should not hear the prompt now. </HELP>
    <PROMPT> This step tests help prompts.
      Say ‘help’ twice. Then say ‘done’ to
      choose another test. </PROMPT>
    <INPUT TYPE=”OPTIONLIST”>
      <OPTION NEXT=”#end”>done</OPTION>
    </INPUT>
</STEP>

Koden ovan illustrerar hur HELP-elementet används för att definera beteendet hos applikationens respons om användaren säger ”help”.

På rad två defineras hjälpmeddelandet som används första gången användaren påkallar hjälp.
På rad fyra defineras hjälpmeddelandet som skall användas andra och alla följande gånger som användaren påkallar hjälp.

Notera att med hjälp av REPROMPT-attributet kommer PROMPT:en repeteras efter det första hjälpmeddelandet men ej efter följande hjälpmeddelanden.

ORDINAL-attributet fungerar på samma sätt som för ERROR-elementet.

INPUT

INPUT-elementet används för att ge användaren möjlighet till interaktivitet.

Utvecklaren av applikationen definerar typ av INPUT likaväl som dess värden.

INPUT-elementet kan endast placeras i STEP-elementet.

ATTRIBUT

Attributnamn

Tillåtna värden

TYPE

DATE
DIGITS
GRAMMAR
HIDDEN
MONEY
NONE
NUMBER
OPTIONLIST
PHONE
PROFILE
RECORD
TIME
YORN

INPUT-elementet Typ:
DATE

DATE används för att få information om ett datum från användaren

SYNTAX

<INPUT TYPE=”DATE”
    NAME=”value”
    [NEXT=”value” [NEXTMETHOD=”value”]]
    [TIMEOUT=”value”] />

ATTRIBUT

Attributnamn

Tillåtna värden

NAME

identifier

NEXT

URL till nästa STEP eller DIALOG

NEXTMETHOD

GET (default)
POST

TIMEOUT

millisekunder (heltal)

EXEMPEL

<STEP NAME=”init”>
    <PROMPT>What is your date of birth?</PROMPT>
      <INPUT TYPE=”DATE” NAME=”dob” NEXT=”#soc”/>
</STEP>

Koden på rad tre använder DATE INPUT för att samla användarens födelsedag, sparar den i VoxML variabeln ”dob” och går sedan till STEP-elementet med namnet ”soc”.

Datumformatet sparas i en VoxML-variabel med standardformat.
Ett fullständigt definerat datum som next Friday, July 10th,1998 sparas som:

07101998|July|10|1998|Friday|next

Ofullständiga datumangivelser sparas som:

July 14th

????????|July|4|||

Tomorrow

????????|||||tomorrow

The 15th

????????||15|||

Monday

????????||||Monday|

OPTION

OPTION-elementet används för att styra applikationens beteende vid en specifikt respons från användaren.

OPTION-elementet kan endast härbergeras inom INPUT-elementet, och då endast när typen OPTIONLIST används.

SYNTAX

<OPTION [NEXT=”value” [NEXTMETHOD=”value”] ] [VALUE=”value”] >
    text
</OPTION>

ATTRIBUT

Attributnamn

Tillåtna värden

VALUE

literal value

NEXT

URL till nästa STEP eller DIALOG

NEXTMETHOD

GET (default)
POST

EXEMPEL

<INPUT NAME=”choice” TYPE=”OPTIONLIST”>
    <OPTION NEXT=”#doit” VALUE=”1″> one </OPTION>
    <OPTION NEXT=”#doit” VALUE=”2″> two </OPTION>
</INPUT>

Koden på rad 2 och 3 illustrerar användandet av OPTION-elementet inom INPUT-elementet.

I det här exemplet kommer OPTION-alternativet på rad två att exekveras när användaren svarar med ”one” och alternativet på rad tre exekveras när användaren svarar ”two”.

Om användaren svarade ”one” blir resultatet att värdet av variabeln ”choice” blir ”1” på grund av hur vi använde VALUE-attributet.

Eftersom NEXT-attributet är detsamma för båda OPTION-elementen i vår OPTIONLIST, kommer browsern att fortsätta till STEP-elementet ”doit” vare sig ”one” eller ”two” används.

<INPUT TYPE=”OPTIONLIST”>
    <OPTION NEXT=”http://localhost/vml/weather.asp”>
      weather </OPTION>
    <OPTION NEXT=”http://localhost/vml/news.asp”>
      news </OPTION>
    <OPTION NEXT=”http://localhost/vml/traffic.asp”>
      traffic </OPTION>
</INPUT>

Koden ovan visar på hur man använder OPTION-elementet för att göra ett val av tre möjliga och varje NEXT-attribut har kompletta HTTP URL:er och i motsatts till det tidigare exemplet unika NEXT-attribut.

OPTIONS

OPTIONS-elementet beskriver typen av interaktivt gensvar inom ett givet STEP-element.

Vanligast används OPTIONS-elementet i HELP-element för att erbjuda användaren en lista på korrekta valmöjligheter.

OPTIONS-elementet kan användas överalltdärtext läsaes uppför användaren.

OPTIONS-elementet kan placeras i PROMPT-, EMP-, PROS-, HELP-, ERROR- och ACK-elementen.

SYNTAX

<OPTIONS/>

ATTRIUT

OPTIONS-elementet innehåller inga attribut

EXEMPEL

<CLASS NAME=”helpful”>
<HELP> Your choices are: <OPTIONS/> </HELP>
</CLASS>

Exemplet ovan illustrerar hur OPTIONS-elementet används för att skapa en CLASS, ”helpful”.

Det STEP-element som som direkt eller indirekt anger ”helpful” som PARENT responderar på ”help” genom att säga meddelandet och då expanderar OPTIONS-elementet till en beskrivning av vilka alternativ som användaren kan säga i denna DIALOG.

OR

OR-elementet används för att definera alternativa igenkänningsresultat i ett OPTION-element.

OR-elementet tolkas som ett logiskt ”or” och används för att associera flera igenkänningsresultat med ett enkelt NEXT-attribut.

OR-elementet kan endast användas i OPTION-elementet.

SYNTAX

<OR/>

ATTRIBUT

OR-elementet innehåller inga attribut

EXEMPEL

<INPUT TYPE=”OPTIONLIST”>
<OPTION NEXT=”#coke_chosen”>
coke <OR/> coca-cola
</OPTION>
<OPTION NEXT=”#pepsi_chosen”> pepsi </OPTION>
</INPUT>

Koden illustrerar hur användandet av OR-elementet i ett OPTION-element.

Som du kan se på rad tre i koden ovan så kan användaren svara antingen ”coke” eller ”coca-cola” och få samma resultat, browsern kommer att fortsätta till STEP-elementet med namnet ”coke_chosen”.

PROMPT

PROMPT-elementet används för att definera vilket innehåll iett STEP-element som skall presenteras för användaren.

Innehållet kan vara text- eller audio-innehåll.
Text läses upp med ”text-to-speech”-teknik.Uppläsningen kan kontrolleras med hjälp av BREAK-element för pauser i uppläsningen, EMP-elementet för för att läggain emfas i uppläsningen och PROS-elementet för olika dimensioner av metrik.

AUDIO-elementet specificerar ljud-filer, ljud-effekter och samplat ljud som spelats in från användaren som skall spelas upp.

PROMPT-elementet kan användas i STEP- och CLASS-elementen.

SYNTAX

<PROMPT> text </PROMPT>

ATTRIBUT

PROMPT-elementet innehåller inga attribut

EXEMPEL

<STEP NAME=”init”>
    <PROMPT> How old are you? </PROMPT>
    <INPUT TYPE=”NUMBER” NAME=”age” NEXT=”#weight”/>
</STEP>

I det här exemplet kommer texten ”How old are you?” att läsas upp med ”text-to-speech”-teknik.
Sedan väntar applikationen på användarens svar.

PROS

PROS-elementet (eng. prosody, sv. metrik) kontrollerar metriken med vilken innehållet presenteras för användaren via PROMPT-, HELP-, ERROR-, CANCEL- och ACK-elementen. Metrik påverkar vissa kvaliteter i ”text-to-speech”-presentationen, som talets tempo, höjd, räckvidd och volym. Den exakta effekten avgörs av kapaciteten hos den TTS-motor som används.

PROS-elementet kan användas inom PROMPT-, EMP-, PROS-, HELP-, ERROR-, CANCEL- och ACK-elementen.

SYNTAX

<PROS [RATE=”värde”] [VOL=”value”] [PITCH=”value”] [RANGE=”value”]>
    text
</PROS>

ATTRIBUT

Attributnamn

Tillåtna värden

RATE

Talets vidd i ord per minut (heltal)
135 är normalt (300 är mycket snabbt)

VOL

Volym (heltal)
1.0 är maximalt, 0.0 är tyst

PITCH

Hz (heltal)
En kvinnoröst är normalt från 140-280 Hz.
Mansröster mellan 70-140 Hz.

RANGE

Hz (heltal)
Kvinnoröst från 80 Hz upp.
Mansröst 40-80 Hz.

EXEMPEL

<PROMPT> Let me tell you a secret:
    <PROS VOL=”0.5″> I ate the apple. </PROS>
<PROMPT>

I exemplet talas ”I ate the apple” med halva den normala volymen.

Att sätta metrikvärdena

Det finns fyra sätt att specificera värdena i PROS-attributet.

  • Som ett absolut värde. Ex: RATE=”100″ för att tala något långsammare än vanligt tal.
  • Som relativt värde. Ex: RATE=”-50″ ger 50 ord mindre i minuten än det aktuella värdet, RATE=”+.25″ dubblerar det aktuella värdet om det är satt till .25 förnärvarande.
  • Som en relativ procentuell förändring av värdet. Ex: RATE=”+50%” ökar värdet med 50% från aktuellt värde. VOL=”+100%” dubblar alltså den nuvarande volymen.
  • Som en återgång till default-värde. RATE=”RESET” återställer hastigheten till default-värdet hos den implementation av VoxML-browser du använder.

RENAME

RENAME-elementet används om du använder en egen grammatik.

I VoxML lagras resultatet av varje igenkänning i separata ”slots” och
genom default-värdet ser INPUT GRAMMAR till att varje slot hamnar i en
VoxML-variabel med samma namn.

Detta innebär också att du inte kan använda samma grammatik för att samla flera
bitar av information, detta avhjälper du med hjälp av RENAME-elementet.

RENAME specificerar en ”mappning” mellan igenkänningsnamnet och variabelnamnet.

Om du tycker att det här var svårt att begripa så var lugn, exemplet nedan gör det betydligt klarare.

RENAME-elementet kan endast användas i INPUT-elementet, och då endast när typen INPUT GRAMMAR används.

SYNTAX

<RENAME RECNAME=”value” VARNAME=”value”/>

ATTRIBUT

Attributnamn

Tillåtna värden

VARNAME

identifiering (identifier)

RECNAME

identifiering (identifier)

EXEMPEL

<INPUT TYPE=”GRAMMAR”
SRC=”http://www.casselbrant.com/docs/voxml/mygram.grm
NEXT=”http://www.casselbrant.com/docs/voxml/vox.htm”>
    <RENAME VARNAME=”sym” RECNAME=”symbol”>
    <RENAME VARNAME=”detail” RECNAME=”quotetype”>
</INPUT>

I exemplet ovan så används RENAME-elementet för att hålla isär variabelnamn från en egen grammatik med dem som förväntas från en annan applikation.

Då två källor kan tänkas var utvecklade på olika håll används RENAME-elementet för att kunna koppla grammatiken med applikationen.

RESPONSE

RESPONS-elementet används i lägen då man vill ha fullständiga uppgifter från användaren.

RESPONS används för att kontrollera vilka slots från igenkänningen som är fyllda.
Detta ger utvecklaren en möjlighet att med NEXT-attributet dirigera användaen till olika URL:er beroende på vilken respons användaren har gett.

RESPONS-elementet kan endast användas inom INPUT-elementet och då endast när typen GRAMMAR används.

SYNTAX

<RESPONSE FIELDS=”value” [NEXT=”value” [NEXTMETHOD=”value”]]/>

eller

<RESPONSE FIELDS=”value” [NEXT=”value” [NEXTMETHOD=”value”]]>
    SWITCH-element
</RESPONSE>

ATTRIBUT

Attributnamn

Tillåtna värden

FIELDS

Kommaseparerad lista på slots

NEXT

URL till nästa STEP

NEXTMETHOD

GET (default)
POST

EXEMPEL

<INPUT TYPE=”GRAMMAR” SRC=”gram://.Banking/action/amt/fromacct/toacct” NEXT=”#notenoughfields”>
    <RESPONSE FIELDS=”action, amt, fromacct, toacct” NEXT=”#doit”/>
    <RESPONSE FIELDS=”action, amt, fromacct” NEXT=”#asktoacct”/>
    <RESPONSE FIELDS=”action, amt, toacct” NEXT=”#askfromacct”/>
    <RESPONSE FIELDS=”action, amt” NEXT=”#askaccts”/>
    <RESPONSE FIELDS=”action” NEXT=”#askamtaccts”/>
</INPUT>

Exemplet ovan visar hur man kan använda RESPONSE-elementet för att hantera en situation där användaren specificerat mindre än alla variabler möjliga i ordlistan (grammar).

Exemplet visar också hur man kan arrangera insamlandet av information genom att använda RESPONS-elementet tillsammans med NEXT-attributet för att bara gå vidare till den information som användaren ännu ej lämnat.

STEP

Varje VoxML-DIALOG måste innehålla ett STEP-element som heter ”init”. Exekveringen av en VoxML-applikation startar med STEP=”init”.
För att avsluta en DIALOG så låter du bli att infoga ett NEXT-attribut i det sista STEP-elementet, eller om du vill skriva tydlig kod så använder du
en ”dummy”, nämligen ett ”#end” STEP.

SYNTAX

<STEP NAME=”value” [PARENT=”value”][BARGEIN=”value”][COST=”value”]>
    VoxML
</STEP>

ATTRIBUT

Attributnamn

Tillåtna värden

NAME

identifierare (identifier)

PARENT

identifierare (identifier)

BARGEIN

Y (default)
N

COST

heltal *(se nedan)

* COST är ett implementationsberoende uppgift om kostnaden för att påbörja eller avsluta aktuellt STEP-element.

EXEMPEL

<STEP NAME=”askpython” PARENT=”tvrating”>
    <PROMPT> Please rate Monty PythonŽs Flying Circus on a scale of 1 to 10. </PROMPT>
    <INPUT NAME=”python” TYPE=”NUMBER” NEXT=”#drwho” />
</STEP>

Exemplet visar ett enkelt STEP-element som samlar in användarens åsikt om en TV-show.

I exemplet kan man tänka sig att man kan använda PARENT-attributet för att dela en uppsättning HELP- och ERROR-element med andra STEP-element som vill ha användarens åsikt om olika TV-shower.

Exempelvis kan man här lägga in vanliga felmeddelanden och/eller en förklaring för användaren hur värderingen 1 till 10 vägs.

SWITCH

SWITCH-elementet används för att definera applikationens beteende beroende på värdet i ett specifikt slot.

SWITCH-elementet används enbart i kombination med CASE-elementet.

SWITCH-elementet kan enbart användast i INPUT-elementet och då endast när typen GRAMMAR används.

SYNTAX

<SWITCH FIELD=”value”>
    VoxML
</SWITCH>

ATTRIBUT

Attributnamn

Tillåtna värden

FIELD

identifierare (identifier)

EXEMPEL

<INPUT TYPE=”GRAMMAR” SRC=”grm://.Banking/action/amount/fromacct/toacct”>
    <SWITC FIELD=”action”>
      <CASE VALUE=”transfer” NEXT=”#transfer” />
      <CASE VALUE=”balance” NEXT=”#balance” />
      <CASE VALUE=”activity”>
        <SWITCH FIELD=”fromacct”>
          <CASE VALUE=”checking” NEXT=”#chxact” />
          <CASE VALUE=”savings” NEXT=”#savact” />
        </SWITCH>
      </CASE>
    </SWITCH>
</INPUT>

Exemplet ovan visar hur man kan använda SWITCH-elementet för att bestämma nästa steg att exekvera på grundval av användarens val i en bank-applikation.

VALUE

VALUE-elementet används för att presentera värdet hos VoxML-variabler via ”text-to-speech”-teknik.

VALUE-elementet kan användas överallt där text skall läsas för användaren.

VALUE-elementet kan du använda i ett PROMPT-, EMP-, PROS-, HELP-, ERROR-, CANCEL- och ACK-element.

SYNTAX

<VALUE NAME=”value” />

ATTRIBUT

Attributnamn

Tillåtna värden

NAME

identifierare (identifier)

EXEMPEL

<STEP NAME=”thanks”>
    <PROMPT> Thanks for your responses.
      I’ll record that <VALUE NAME=”first”/> is your favorite and that

      <VALUE NAME=”second”/> is your second choice. </PROMPT>
    <INPUT TYPE=”NONE” NEXT=”/recordresults.asp” />
</STEP>

Exemplet ovan visar hur VALUE-elementet läser upp de val som användaren har gjort tidigare i applikationen.