Canadian Broadcasting in XML
May 25, 2005
Ask someone who's been observing the XML scene for a few years about XML in the context of cell phones and similar devices (PDAs and so on). What you'll get from them will probably include references to WML, WAP, and various web services. What you most likely won't get from them will be anything regarding XML-based descriptions of cellular and PCS broadcast systems.
The latter is the subject of this month's "XML Tourist."
Mobile Broadcast Regulation in Canada
In the United States, regulating the broadcast spectrum--including the cellular/PCS frequencies--falls to the Federal Communications Commission (FCC) and various state agencies. In Canada, this is the work of Industry Canada's Spectrum Management Services.
"Regulation" in this sense doesn't mean monitoring the content of broadcasts. What's at issue is that only a limited number of radio frequencies are available in a given geographic area for each general type of broadcasting--AM, FM, cellular, and so on. The companies who provide broadcast services participate in frequency auctions to acquire the right to use specific frequency ranges. One way to determine that the assigned frequencies, and no others, are being used by a given provider might be termed "reactive": if that provider's broadcasts interfere with another's, the interfering provider is essentially trespassing on territory "owned" by the other provider and can be subject to fines or other penalties.
Much better than waiting around until someone oversteps their prescribed frequency ranges, though, is to monitor, proactively, the types of broadcasting equipment they're using in the first place. Not all antennas are created equal: some stand 50 meters tall and some shorter or taller; some are positioned on high elevations and others in lower-lying areas; some broadcast at significantly higher power than others; and so on. To take an extreme example, a transmission antenna that is only a half-meter tall and broadcasts a relatively weak signal may not threaten anyone else's transmissions or receptions at all, even if its broadcast frequency spills above or below the assigned range.
With these considerations in mind, Spectrum Management Services has, since fall 2004, required broadcasters to periodically upload data about all cellular/PCS stations and antennas that they operate. The service providers can upload the data either in ASCII text form or--no surprise--as XML.
Here's a portion of the first record in the sample text file available from Spectrum Direct, the Service Management Services website (broken into multiple lines for legibility):
92900001,"Sub. #23-1, Aug/04",James Watson, 6139412262,,watson.james@ic.gc.ca,, Ottawa ON - 300 Slater St.,ON,83,452428, 754245,80...
And here's the same data in XML form:
<station_data
xmlns="http://sd.ic.gc.ca/station_data_en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://sd.ic.gc.ca/station_data_en
station_data_en.xsd">
<account>
<company_code>092900001</company_code>
<reference_number>Sub. #23-1, Aug/04</reference_number>
<contact_name>James Watson</contact_name>
<telephone>6139412262</telephone>
<email_address>watson.james@ic.gc.ca</email_address>
<station>
<location>Ottawa ON - 300 Slater St.</location>
<province_code>ON</province_code>
<nad27_83>83</nad27_83>
<latitude>452428</latitude>
<longitude>754245</longitude>
<site_elevation>80</site_elevation>
...
</station>
...
</account>
</station_data>
(Which do you prefer? Me too -- and not just because I'm writing about it!)
As you can see, the data file includes some general information about the company (account) providing this upload; contact name, telephone number, and so on. Each broadcaster might have only one "station"--basically, the location of the broadcast facility--or it might have more than one station (by far the norm). Not shown above is data about the antennas placed at that station. Here's an example of data about a single antenna:
<antenna> <tx_frequency>1950</tx_frequency> <upper_tx_frequency>1965</upper_tx_frequency> <rx_frequency>1870</rx_frequency> <upper_rx_frequency>1885</upper_rx_frequency> <bandwidth>1250</bandwidth> <class_emission>F9W</class_emission> <tx_power_w>8</tx_power_w> <tx_ant_manufacturer>ZZ</tx_ant_manufacturer> <rx_ant_manufacturer>ZZ</rx_ant_manufacturer> <tx_ant_model_no>PCSS090-13-2</tx_ant_model_no> <rx_ant_model_no>PCSS090-13-2</rx_ant_model_no> <tx_ant_height>55</tx_ant_height> <rx_ant_height>55</rx_ant_height> <tx_ant_azimuth>120.0</tx_ant_azimuth> <rx_ant_azimuth>120.0</rx_ant_azimuth> <tx_ant_gain>16</tx_ant_gain> <rx_ant_gain>16</rx_ant_gain> <tx_ant_pattern>8200</tx_ant_pattern> <rx_ant_pattern>8200</rx_ant_pattern> <tx_line_loss>3.2</tx_line_loss> <rx_line_loss>3.2</rx_line_loss> </antenna>
If the antenna at that station is omnidirectional, there will be only a single
antenna element; otherwise there will be one per unidirectional
("sectorial") antenna located there. The elements whose names are prefixed
tx_ and rx_ represent, respectively, the antenna's transmission
and reception characteristics. Element names referring to "azimuth" define the
compass direction in which the antenna is aimed (0 degrees if omnidirectional, 360
degrees
if directional pointing due north, and so on--the antenna described above is aimed
roughly
east-southeast). The antenna_pattern element has a string-value of 8000 if
omnidirectional, 8200 if (like this antenna) unidirectional. Other
elements--tx_power_w, rx_ant_gain, etc.--spell out various
technical characteristics of the antenna. (Descriptions of all elements are available
in a PDF document at Spectrum
Direct.)
Now, I've no idea whether Canadian cellular/PCS providers find these data requirements
burdensome. But just to head off one objection--that their systems change very little
over
time--Spectrum Management Services provides an alternative form of the data file.
In its XML
guise, this replaces all the station elements (and their descendants) with a
single empty no_system_changes element:
<station_data
xmlns="http://sd.ic.gc.ca/station_data_en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://sd.ic.gc.ca/station_data_en
station_data_en.xsd">
<account>
<company_code>092900001</company_code>
<reference_number>Sub. #23-1, Aug/04</reference_number>
<contact_name>James Watson</contact_name>
<telephone>6139412262</telephone>
<email_address>watson.james@ic.gc.ca</email_address>
<no_system_changes/>
</account>
</station_data>
Thus, even when there have been no changes to the stations described in its previous upload, the broadcaster can continue to follow the periodic data upload cycle.
On receipt, Industry Canada validates each submission. If the submission isn't of the "no changes" variety, its contents are added to an Assignment and Licensing System (ALS) database (completely replacing any earlier data for the same service provider's stations and antennas).
Working with Raw XML Data
While researching the Industry Canada cellular/PCS station data formats, I came across one other tidbit which the agency offers to simplify service providers' data preparation. This is a "stylesheet" of sorts, but one following neither the CSS nor the XSLT standard. Instead, it's a stylesheet expressly intended for use with Altova's Authentic XML editor.
(Altova is probably better known--it certainly was to me--as the developer of the popular XML Spy editor. The Authentic product might be thought of as a free, reduced-feature-set version of XML Spy.)
The XML dialect in which this stylesheet is coded is Altova's own StyleVision Power Stylesheet (SPS) language, typically produced not by hand, but as output from (yes) Altova's StyleVision stylesheet editor. Authentic uses SPS stylesheets to display and manipulate data in a way similar to typical web-based forms.
Here's a portion of the SPS stylesheet provided by Industry Canada for use by cellular/PCS license holders:
<structure version="2"
schemafile="station_data_en.xsd"
workingxmlfile="station_data_en.xml"
templatexmlfile="">
<nspair prefix="n1"
uri="http://sd.ic.gc.ca/station_data_en"/>
<nspair prefix="xsi"
uri="http://www.w3.org/2001/XMLSchema-instance"/>
<template>
<match overwrittenxslmatch="/"/>
<children>
<template>
<match match="n1:station_data"/>
<children>
<template>
<match match="n1:account"/>
<children>
<newline/>
<paragraph paragraphtag="h1">
<children>
<text fixtext="Upload and Account Details:">
<styles font-family="Arial"
font-size="large"/>
</text>
<template>
<match match="n1:company_code"/>
<children>
<xpath allchildren="1">
<styles font-family="Arial"
font-size="large"/>
</xpath>
...
</children>
</template>
</children>
</paragraph>
</children>
</template>
</children>
...
</template>
</children>
</template>
...
<pagelayout>
<properties pagemultiplepages="0"
pagenumberingformat="1" pagenumberingstartat="1"
paperheight="11in" papermarginbottom="0.79in"
papermarginleft="0.6in" papermarginright="0.6in"
papermargintop="0.79in" paperwidth="8.5in"/>
</pagelayout>
</structure>
As you can see, it's something like an amalgam of XSLT (e.g., all those
template elements), HTML (the reference to an "h1"), and XSL-FO
(the pagelayout element's contents, obviously describing a physical page rather
than layout in a browser window). While perfectly well-formed XML, it also departs
from
convention in several ways, most notably (for me) in its use of those rather strange
nspair elements up towards the top, each of which makes an element and a
couple attributes do, apparently, the same work as plain old namespace declarations.
Here's a screen shot of the sample XML data file from the Spectrum Direct site, using their SPS stylesheet, when viewed in Authentic:
See? It's just like a Web form, except that it requires neither a server nor any programmatic validation. The combination of the document's schema and the presentation laid out in the SPS stylesheet (like the select lists for Province Code and Coordinate Format) keeps the data entry clean.
All in all, I'd have to say that the Industry Canada data-collection effort, with its simple XML schemata and SPS stylesheet, fairly puts the lie to complaints (still lingering) that XML applications are too difficult to use -- and provide too little payback -- for small-scale data sets. I've neither expertise nor interest in providing cellular or PCS service in Canada; but obviously, if I did, regularly describing my systems to government regulators would be the simplest of tasks before me!