The User Gets the Stats
- Submitting the Data
- What Faces the Customer
- How the Data Is Gathered
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Submitting the Data
As discussed previously, there are actually two links in the human chain of sports score reporting: data production and data consumption. Sure, the actual data is produced by the hard-working men and woman on the grass, turf, and parquet of the world's exhibition arenas, but are they sitting at a terminal providing a take on the games happenings for use by cube rats unable to attend? Maybe in the XFL, but what are the fans of good sporting events to do?
Fortunately, the only capability that the data producer requires is to submit a form. Just to make things a little easier, the producer client will manage only a single event per browser instance. The frameset page is constructed and returned when a call to mode=add is made. This should be only known, trusted persons, but a user ID/password combination could easily be added for extra security. In the early incarnations of the system, when all the data providers are known, a link with the necessary query string could be mailed to the correct person. Figure 1 is an example of what a provider might see.
){kind=link}
Figure 1 Possible layout of data provider display.
The simple interface is critical for two basic reasons: People attending sporting events drink, and they don't carry large monitors. The functionality is limited at this time, but relying on human updates to the database is limiting itself. This way a data producer only needs to carry a pager or cell phone to update others on the progress of the home team.
By loading a recordset as XML, here's what we receive:
<update>
<sport>Baseball></sport>
<team>Seattle Mariners</team>
<score>8</score>
<team>Texas Rangers</team>
<score>1</score>
<description>[description text]</description>
</update>
Included is a browser version for someone who is sitting in a luxury box with a laptop and a Wireless Markup Language (WML) version for those in the stands with a cell phone. WML is another entry in the alphabet soup of the new face of the Internet. Almost a throwback to the days of multiuser dungeons and Telnet, WML is an update of Handheld Device Markup Language (HDML) wrapping XML in addition to HTML. Of course, there are HTML elements, but with wireless communication still very much focused on the most data for the minimal overhead, XML is a necessary component.
This sort of situation is exactly the sort for which XML style sheets were created. By taking the minimal information that must be submitted—the team, the score, and the description, along with a hidden control containing the game ID—and information about the browser making the updates, an XSL transform can convert the data into the correct HTML for display.
An XSL transformation essentially searches the XML files for patterns that it recognizes and converts them into the correct form—for example:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="text" indent="no" />
<xsl:template match="/">
<xsl:for-each select = "./sport"><b><xsl:value-of select="./"/></xsl:for-each>
</xsl:template></b>
</xsl:stylesheet>
All that this portion of the style sheet attempts to do is take any instance of the <sport> element and wrap the value in <b> tags. Wrapping around this template would be a loop for searching all data elements and wrapping each in the correct table tags. The templates then determine the format of the data within those tags. When you change the templates, the display format (and the associated code) changes.
This is important for two basic reasons: one related to future data, and one related to future devices. If additional data values become columns in the database, those values simply need to be added to the data XML. Simply denote the type of control needed to handle the data, and the XSL will wrap the control snugly in the browser-specific rendering code. If you decide that a new control type should be available, just create a new template entry in the XSL. A new browser of any type simply calls for a new XSL. If a browser does not support a type of control, the XSL simply ignores that data item.
Provided that the submission interface is usable and readily understandable, the graphical appearance is not very important. This is especially true for the current crop of cell phones. In the case of the user interface, however, XSL takes on a new dimension.