| Previous | Table of Contents | Next |
The documents in the preceding chapters all corresponded to real paper documents, the kind of documents that people can pick up and read. XML isn’t limited to this kind of information; indeed, many of its earliest applications supplied information in forms not readily presentable to humans. The field in which XML may make the greatest strides is communication between computers and between computers and other devices, which has been a difficult affair so far. The DTDs and other examples in this chapter provide solutions for what I call nontraditional documents—data structures for which XML is very appropriate but that aren’t documents humans would normally read.
Our first example applies XML to a rather different computing field—device control. Given a system that responds to a small set of inputs without requiring processing of return values, it is possible to write a “program” purely in data. For starters, we’ll build a DTD that could be used to control a set of light switches (or other electrical devices). Light switches are an extremely simple example, but there are many situations with hundreds or thousands of lights that need to be controlled. Our example will begin with the lighting in a typical house, but it could be extended to cover display lights or even stage lights.
My parents used to receive the DAK catalog every few months; it was crammed with odd and unusual stereo equipment and gadgetry. One of the weirdest items they carried was the X-10 system, which let you control electrical devices by remote control. Originally it came with a controller unit and modules that plugged in between the electrical socket and the plug of a lamp or other electrical device. The controller unit sends signals over the electrical wires to the individual boxes (up to 256 of them) telling them to turn on and off or dim to a particular level. Eventually it sprouted a serial computer interface, which made it easy to program devices to turn on and off at various times of day—effectively, a more expensive, but more accurate device timer than the boxes with the dials on them. At this point, it’s grown considerably more elaborate (see http://www.x10.com for details). Remote controls that can run a house rather than a TV make it easy for the ultimate couch potatoes to run significant portions of their houses without getting up.
Although the DTD we’ll develop isn’t designed expressly for the X-10 interface, it wouldn’t be too difficult to build an interface that converted the data in these documents into the signals controlling electrical devices. The X-10 system actually uses a limited set of commands to control its devices, but our DTD doesn’t need to worry about particular commands. It will just define particular states that the control system should achieve. A processing application would take the information returned by the parser and determine which commands are needed to achieve the state desired. Instead of giving the controller a sequence of steps, our document will give it a desired result and allow the controller to figure out how best to get there.
We’ll be controlling two different categories of equipment: lights and appliances. Lights can be turned on and off and dimmed, whereas appliances can be turned on and off. (If someone wants to extend this to controlling appliances via remote controls and not just their power, extending the DTD shouldn’t be too difficult.) Lights and appliances are identified by addresses that effectively represent hexadecimal numbers. The address begins with a house code, A–P. General practice is to set up an entire system on one letter, limiting users to 16 devices but avoiding conflicts with neighbors. Users without gadget-minded neighbors can use more than one house code. The unit code identifies the controlling module. It’s a number from 1 to 16. Device modules can be set to the same address; all device modules with the same address will respond simultaneously to commands. A set of three lamps on address B10 will all turn on or off or dim as requested in response to commands sent to B10.
Our DTD will allow users to create documents to give orders to this system. All these documents will be processed by a computer, but we’ll keep them human-readable for easy editing. To help with this, our documents may include a description of all the modules on the system, followed by the states desired and the conditions that set them off.
<!ELEMENT CONTROLSCHEDULE (MODULE*, STATE*, TRIGGER*)>
Our modules need several identifiers. For now we’ll stick with the system that X-10 uses to build an address, adding two pieces that provide additional information to the processing application and human editors:
<!ELEMENT MODULE (ADDRESS, TYPE?, DESCRIPTION?)> <!ELEMENT ADDRESS (HOUSE, UNIT)> <!ELEMENT HOUSE (#PCDATA)> <!ELEMENT UNIT (#PCDATA)> <!ELEMENT TYPE (#PCDATA)> <!ELEMENT DESCRIPTION (#PCDATA)>
We give the MODULE element a little bit of extra flexibility by allowing it to contain ADDRESS and TYPE elements. We could require the user or the program creating these files to keep track of whether the module at a particular address is a light module or an appliance module and to identify the modules purely through addresses. Adding TYPE adds some extra flexibility and makes these documents more portable. A processing application that doesn’t care about TYPE can strip it out, whereas a new application that’s being set up for the first time might use the TYPE element to import more complete information about the control modules. TYPE also adds a bit of flexibility in case new varieties of a module appear because commands may vary depending on the kind of module receiving them. (At present, the X-10 system doesn’t, but a more advanced future system might.) DESCRIPTION is provided to give the humans programming these devices a description of the device and its location.
The ADDRESS element allows us to identify modules uniquely (or in sets, as described previously.) A developer impatient with the A–P, 1–16 identifiers of the X-10 system could convert them to their hex equivalents easily and represent them in the DTD like this:
<!ELEMENT ADDRESS (HEXADDRESS | (HOUSE, UNIT))> <!ELEMENT HEXADDRESS (#PCDATA)>
For now, we’ll stick to using the HOUSE and UNIT identifiers.
| Previous | Table of Contents | Next |