SALT Forum advances Mobile Content Delivery

SALT Forum advances Mobile Content Delivery

SALT Forum advances Mobile Content Delivery

The SALT (Speech Application Language Tags) specification pairs speech with HTML, XHTML, and XML. The specification boasts a 70-member consortium of backers including industry heavyweights Microsoft, Cisco, and Intel. The group submitted SALT 1.0 to the W3C. SALT is not a W3C standard, though. SALT was submitted to the W3C’s Voice Browser working group, which will consider it as a part of the next VoiceXML standard. This article will touch on the SALT/VoiceXML relationship again near the end.

Because SALT is implemented at the HTML, XHTML, and XML level, it shields developers from some of the complexity of working with individual vendor speech APIs. Both users and developers benefit from SALT’s ability to add speech capability for a multitude of devices—traditional PCs as well as telephones, PDAs, and other devices.

SALT actually goes beyond just the “speech” part of its name, though. The SALT specification includes “multi-modal” access, which means the user can access the application through a variety of input methods. Speech is the obvious one, but SALT also provides support for telephone keypads and for mixed mode input where a user can switch between typing or pointing for input and providing input via speech. For output, a SALT application can provide multiple output types as well including traditional text and graphics, synthesized speech, and audio. The application should detect the proper output type for the user client device and respond accordingly.

Processing SALT applications is done differently depending on the type of client platform. For example, when a user accesses a SALT-enabled Web page from a PC, the PC will provide the processing horsepower to take the speech input and turn it into input for the server. Likewise, the PC will render any text-to-speech audio output. On the other hand, SALT access from a processorless device such as a telephone depends  on a SALT-enabled server for the user to call into. In that scenario, the server processes the user speech into commands and the audio output is rendered server-side as well. With Microsoft backing, SALT is of course a part of the .NET Framework for Microsoft developers. Microsoft has a speech SDK (it is still in beta at this time) for .NET developers, which uses SALT. Developers should be familiar with ASP.NET before attempting to work with SALT.

In a sense, SALT is a competitor to the VoiceXML standard for speech applications. However, SALT does incorporate some VoiceXML and the related W3C standards SRGS (Speech Recognition Grammar Specification) and SSML (Speech Synthesis Markup Language), so the two are not completely separate items.

SALT will probably appeal more to Microsoft developers and other developers coming in to speech from a Web development background. Experienced Web developers will understand the SALT development model because it uses the event-model most Web applications are built on.

VoiceXML could be more appealing to developers with a background in traditional telephony or IVR (Interactive Voice Response) applications. VoiceXML could also be more appealing where the application has a very strict flow definition, like the ones you would find traditionally serviced well by an IVR application. VoiceXML is a larger standard because it is a complete standalone markup specification where SALT depends more on existing functionality handled by other Web application specifications. VoiceXML also has the advantage of being a more widely supported standard, with more than 250 companies involved in the VoiceXML Forum. VoiceXML is a more mature standard as well, now in a ratified version 2.0 with the original specification dating back five years to 1999. However, SALT supporters point out that VoiceXML’s maturity can also be a SALT advantage. VoiceXML has roots in an earlier Web era where SALT is based in more modern Web development architecture.

For further reading, Hitesh Seth has a series of five SALT articles on, starting with an introduction SALT: By Example, which quickly dives into some SALT code.

About SALT:

The Speech Application Language Tags (SALT) 1.0 specification enables multimodal and telephony-enabled access to information, applications, and Web services from PCs, telephones, tablet PCs, and wireless personal digital assistants (PDAs). The Speech Application Language Tags extend existing mark-up languages such as HTML, XHTML, and XML. Multimodal access will enable users to interact with an application in a variety of ways: they will be able to input data using speech, a keyboard, keypad, mouse and/or stylus, and produce data as synthesized speech, audio, plain text, motion video, and/or graphics. Each of these modes will be able to be used independently or concurrently.

The SALT Forum brings together a diverse group of companies sharing a common interest in developing and promoting speech technologies for multimodal and telephony applications. Founded in 2001 and representing over 70 technology leaders, the SALT Forum seeks to establish and promote a royalty-free standard that provides spoken access to many forms of content through a wide variety of devices.
In pursuit of these goals, Version 1.0 of the SALT specification, was developed by Forum members and contributed to the World Wide Web Consortium (W3C). Membership in the SALT Forum is open to all.

The Founders about SALT:

“The ability to add speech to graphical applications will contribute to further growth in the rapidly expanding VoIP market and will enable delivery of innovative and interoperable value-added communications and services over a single packet network.”
— Alistair Woodman, Director of Marketing, Voice Technology Center
Cisco Systems

“Multimodal user experience is the natural way of interaction for end users. The ability of end users to choose their preferred mode of interaction at any point during a transaction will drive the take rate and the usage of new voice and data services. Comverse is committed to evolving its platforms to enable the development of multimodal revenue generating applications and services for 2.5 and 3G networks, including our messaging, personal communications and entertainment products along with the Spark Alliance Program. An open standard supported by major industry leaders will significantly increase the penetration and delivery of enhanced voice and data communications services.”
— Zeev Bregman. CEO

“Intel endorses the delivery of open, standards-based speech tags to foster another wave of innovation on the Web and within communications networks. The addition of speech to text and graphics as a human interface increases computing device ease of use and benefits business and consumers. Call control expertise will enable developers to offer basic and enhanced calling features within their applications. Intel will deliver industry-leading performance for applications using Speech Application Language Tags when run on Intel platform architectures designed for desktop, mobile and tablet PCs, cell phones, PDAs and other wireless devices as well as a range of communication and Web servers.”
— Howard Bubb, Vice President and General Manager, Telecommunications and Embedded Group

“As part of our commitment to provide leadership in enabling speech access to Web applications and services, Microsoft will offer Web developer tools to implement SALT, including providing SALT extensions for Visual Studio® .NET and ASP.NET technologies, as well as extensions for Microsoft Internet Explorer and Pocket Internet Explorer Web browser software. We’re delighted to join with these major industry players to create a critical mass behind an open, independent infrastructure that will make natural-speech access to applications and the Web a reality.”
— Kai-Fu Lee, Vice President, Natural Interactive Services Division

“Philips technology encompasses all that SALT will unite: a convenient speech user interface for all kinds of devices providing input along with feedback via speech or on display. Thus SALT will make it even easier to use applications with Philips technology inside. Now it will be possible for you to ask your car navigation system for directions, as well as tell it to display the Web page with the hotels along the way from the Yellow Pages — all with just your voice.”
— Frank Caris, President
Philips Speech Processing North America

“Scansoft has invested in multimodal technologies, through both its networked and embedded speech-recognition and text-to-speech, and sees this founding initiative as critical to the success of multimodal applications in our industry. We have seen strong early-stage demand for multimodal applications and believe a standards initiative is key for widespread adoption.”
— Steve Chambers, general manager
For further reference see:

Handling Lightweight Objects

Handling Lightweight Objects

Handling Lightweight Objects

The cores of everyone’s development efforts are classes. You’ve got down the basics of creating methods in your objects, you know how to keep them lightweight, and you’re familiar with all of the syntax necessary to implement your ideas. However, what do you do when you have to think about how your object lives and breathes internally, not what it exposes to the world?

Internal vs. External

The way that an object exposes itself and the way that it behaves internally, can and should be different. Objects expose themselves in ways that makes them easy to use for the developer. They work in ways internally that hide all of the complexity from their external developer-users.

This is particularly true of lightweight objects, which behave externally like they are always fully populated while internally they only initialize the pieces of the object that they need. Take, for instance, a product object, which supports collection properties for related products, categories, attributes and vendors. Externally, the developer can access these properties at any time. Internally, the object populates the collections only when the user asks for them since each means a separate database hit. Internally, there are private fields that may or may not be initialized. Externally, the collection is always returned even if there is nothing in the collection.

Another example would be a property that represents the last user that updated the product. The internal storage might be the users’ GUID. The property might, however, return a user object. In this case, the way that the object behaves internally, managing a GUID, is different than the way it behaves externally, returning a user object.

These distinctions are important when you look to develop persistence and serialization strategies. In both of these cases the way that the object is stored isn’t necessarily the way that the developer uses it. What you store in a database, and what you use to transport the object, isn’t the properties that the object exposes. It is the internal fields that must be populated for the object to be the object. It’s the data in the object that distinguishes it from other objects. An object without data is simply the class.


Developing a persistence strategy whether to a database, text files, or some other mechanism isn’t for the faint of heart. Organizations have spent years trying to get their persistence strategy right. However, there is one basic fundamental truth. Objects must persist themselves as they see themselves internally. They save and read GUIDs, identifiers, and simple fields. One to many relationships represented in the object as collections are stored in the database as sets of key values in varying tables.

Powerful persistence strategies are developed on automated means of taking all of the fields within the object and storing them. This includes all of the fields from super classes. Persistence strategies include an understanding of how the related objects are stored, however this is done.

Ideally persistence strategies will be simple to implement and difficult to make mistakes. The idea of any strategy is to make it more difficult for errors to occur through the use of procedures, shared code, and tools.


One of the other core challenges that any persistence strategy has to tackle is how to handle nested objects. Nearly every non-trivial object will be made up of objects itself. It’s important to realize that nested objects must persist themselves as well. In developing the persistence strategy it’s important to develop a structure that allows for underlying objects to be persisted when the upper level object is persisted.

The challenge when persisting all of the underlying objects is suppressing extra updates which don’t need to happen since now every request to persist the upper level object will cause the underlying objects to be persisted as well, whether or not they have changed.


Serialization, as it happens, is very similar to persistence. In fact a good serialization should allow for that serialized object to be persisted for an arbitrary length of time. As serialization is pushed into a message queue or some other non-real time communications mechanism it does in fact become temporary persistence of an object. Because of that the mechanisms for serialization should rest upon the same persistence engine that is used to store an object in a more permanent way.

There is one minor exception to this. Occasionally serialized objects are used for other purposes. In one recent project we serialized the basic commerce objects and used XSLT to transform them into emails for the user. In this situation, serializing the internal view of the object works except for the fact that the object may or may not be completely spun up. A lightweight object may or may not have loaded all of their component parts. This may not be desirable. Sometimes it’s necessary to cause an object to load all of the component parts of it self before it’s serialized.

Handling Lightweight Objects

In a previous article I indicated that lightweight objects are a great way to manage performance in an object-oriented world. The challenge is all of the lightweight properties of the object won’t serialize when the object is serialized. At least the properties won’t be serialized when the object hasn’t been fully initialized. For cases like these, your serialization strategy should include a parameter for whether an object needs to be fully initialized before it can be serialized. Further, that parameter should control whether the need to fully initialize lightweight objects should be pushed down through the hierarchy of the objects.

Normally, serialization is allowed to operate without fully initializing lightweight objects. In cases where the outer object is going to be used for non-reconstruction purposes like to generate emails from an ecommerce system it may make sense to fully initialize the outer object. In some cases, it may be necessary to fully initialize inner objects to ensure that the necessary fields are available for the email generation process.


The way that an object views itself and the way that developers view the object are and should be two different things. Hiding the complexity of the underlying operation is an important pillar of the object oriented design model. The right way to handle object persistence and serialization do cause some interesting challenges as you try to use the serialized data for other things, such as the input for XSLTs. These challenges are easily addressed if you know how to prepare.

About the Author

Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach

Learning WML – WAP Basics

Learning WML - WAP Basics

Learning WML – WAP Basics

Windows CE, being a little brother of its desktop counterpart, now exposes most PC communications capabilities. In many cases, they are just a subset of desktop versions, but still may be quite useful. In this article, we will discuss Windows Networking API (WNet). Mobile applications may access a remote host’s file system and other resources via WNet. Your program can establish and terminate network connections, retrieve configuration information, and so forth. Similar to the desktop, WNet communicates to the outer world via CIFS—Common Internet File System redirector—a module, through which one computer can access another one. Network resources are named using Usiversal Naming Convention (UNC).

As noted above, Windows CE supports only some restricted subsets of WNet API. The main limitations are: Microsoft Windows Network is the only network provider currently supported No connections are restored during a warm boot. A persistent connection is stored in the Registry and then may be enumerated and retrieved by calling the WNetOpenEnum function with the dwScope parameter set to RESOURCE_REMEMBERED
You can’t use any drive letters to map network resources No Mail slots or Named Pipes are supported No LaN Manager functions are supported
Windows CE does not support the concept of a computer or device belonging to a specific network context WNet API doesn’t communicate over ActiveSync connection WNet API is compact enough and may be easily overviewed. The following table briefly describes its functions.
Keeping all this stuff in mind, you nevertheless can use WNet pretty effectively for different data transmission tasks. The basic idea here is that, once you know network resource name, you can treat this resource in terms of standard file I/O. The next sections will illustrate some common scenarios your applications may need to implement.

Foreword for MFC Applications

The recent implementation of MFC for Windows CE does not allow using WNet in MFC-based applications. This is a strange fact, but that’s how it is. To work around this issue, add the following lines to stdafx.h:
The origin of all this stuff comes from wce.h header files under the MFC Include folder, where you can find that many API are stored even though there are appropriate headers in the SDK folder. But all in all, WNet is easy to revive by such a simple trick. Enumerating Domain Resources

The first sample we will discuss produces the list of domain network resources. It recursively surfs through domain entries and puts them into the listbox for simplicity. The basic points of this process are listed below:

Call WNetOpenEnum to open the enumeration Sequentually call WNetEnumResource until it returns ERROR_NO_MORE_ITEMS On each successful call of WNetEnumResource process, receive NETRESOURCE data If the current node is of the RESOURCEUSAGE_CONTAINER type, you can use it as a starting point for nested enumeration Close the enumeration handle by using a WNetCloseEnum call Let’s briefly overview this sample. As we have said before, a call to WNetOpenEnum opens a new enumeration. The first parameter, dwScope, controls what should be enumerated. The sample uses a RESOURCE_GLOBALNET value to get all resources on the network. RESOURCE_CONNECTED and RESOURCE_REMEMBERED will give us active connections and previously stored resources respectively. After enumeration has been initiated, the application sequentually calls WNetEnumResource to achieve the next resource data. You are free to do all required processing of this data depending on resource type and usage. The code snippet takes the simplest way—proceeds nested enumerations. This loop ends up when WNetEnumResource returns ERROR_NO_MORE_ITEMS. And finally, WNetCloseEnum releases the enumeration handle. Establishing and Terminating Network Connections

WNet provides several fucntions to establish and to terminate a connection to a network resource. You can use either WNetConnectionDialog1 or WNetAddConnection3 to create a new connection. After a successful call, each one creates a new folder under the ‘\Network’ directory on the device. Notice that the system does not re-connect to mapped resources after a warm reboot. Following are two code snippets to demonstrate the usage of each of these functions.

WNetConnectionDialog1 shows a dialog to map the remote name to a local one. WNetAddConnection3 does the same job silently. Both of them may use a pre-defined NETRESOURCE entry to determine what to do. In addition, WNetAddConnection3 allows remembering this connection as persistent; in other words, it’ll be remembered after a warm reboot.

There are three functions your application may use to cancel the existing connection to network resources:
Each function above results in dropping the connection. WNetDisconnectDialog pops up a dialog with all existing connections. The user then can the select desired resource to get disconnected. WNetDisconnectDialog1 and WNetCancelConnection2 do their job silently. The return code indicates the result of the requested operation. Besides, the last two functions may fail depending on existing open files or jobs that use this connection. The user is informed about all errors that occurred. A simple example of this is shown below:

Reading and Writing Data

And finally, the simplest thing: How can your application conduct I/O operations via WNet? The answer is quite primitive: by using standard file APIs. Once you have detected the UNC name of the network resource and have successfully established a connection to it, you can consider it a ‘file’ name. Thus, a common flow may look as follows:

Establish a connection to the network resource by calling WNetAddConnection3 Proceed with all desired read/write/copy/delete operations Close the connection to the network resource As a result, the application can handle all required I/O operations on remote hosts. The most obvious usage is printing on network printers. In this case, you can either open the selected resource and then use WriteFile to send data to it or simply call CopyFile. The following sample demonstrates it:
This code snippet uses WNet to print on an HP LaserJet printer available somewhere on the network. It uses “Sample.txt” as a test PCL stream to print a cover page of the PCL manual. You may easily create your own printer data by printing some document and choosing the “Print to file” option. Conclusion

As you have seen, WNet under Windows CE is really a simple but useful set of APIs. If your applications work in a networking environment and you want to use network resources, WNet will do its best.

Alex Gusev started to play with mainframes at the end of the 1980s, using Pascal and REXX, but soon switched to C/C++ and Java on different platforms. When mobile PDAs seriously rose their heads in the IT market, Alex did it too. Now, he works at an international retail software company as a team leader of the Mobile R department, making programmers’ lives in the mobile jungles a little bit simpler.

© 2019 ICPE 2015