The geographical aspect of the architectural design on which the Internet and low-level Internet protocols are based is directly contrary to that which would be an ideal basis for the automatic location component of an emergency response system. Additionally, the nature of the Internet encourages further techologies to be built on top as abstractions of the low-level connection protocols, further complicating matters to a greater extent and more rapidly than with conventional telephones.
Since the conventional telephone system relies on a hierarchical switching architecture with physical connection points, and with strict subscriber-based use of these lines, telephone companies by nature maintain complete associations between each live telephone number under their control and its physical installation address. Given this information, along with a caller's telephone number retrieved via caller ID, for example, there can be an instant independent lookup of the physical location of a caller, or at least the physical address of the telephone installation. This can be used to route the call immediately to the local emergency response facility and also to give that facility location information in case the caller is unable to communicate it. Cellular phone users cannot capitalize on such a characteristic since they may roam the world with a single telephone number. However, use of a cellular phone does depend on connection to relatively local connection points (towers), so fairly precise location methods possibly including triangulation of these connection points and/or Global Positioning System (GPS) functions could be imagined. And as far as routing the call immediately to the local emergency response facility, location of the local connection point (tower) should usually be sufficient. I understand that such things are being done and being researched, but are beyond the scope of this question.
The Internet has neither of these aspects inherent in it's structure or base protocols. Surely you might suggest the possibility of widespread inclusion of GPS units in PC's and mandatory integration of them into Internet protocols, or an attempt to integrate information about physical Internet connections into the base protocols. However, even if these were feasible and complete solutions (which they aren't anyway), they would involve either a very huge shift or supplement to the very fundamentals of what makes the Internet the Internet. Therefore, economics would render all such attempts failures. We must instead focus on a constructive solution based on existing technologies and the current state of the Internet.
In most high-level Internet protocols (HTTP, Telnet, etc.), communication is based merely on the IP addresses (and ports) of both parties, so this would likely also be the basis for our Internet 911 system. An IP address or domain name may have a physical (geographic) address associated with its current owner, however this is extremely unreliable and usually not sufficient for our application, as it has no necessary bearing on the physcial location of the computer which actually happens to be using that IP address or domain name or sub-domain name at any given time, not to mention the actual location of the user on that computer (imagine a server with a user from around the globe-). Additionally, issues with dynamic IP addressing schemes, use of shared servers for certain activities (resulting in users from around the world all communicating via the one IP address of the server), and dial-up ISP's (where yet another level of tracing that would rely on something even beyond basic cooperation by all dial-up ISP's would be required), potentially throw off any methods attempting to derive power from some function doing IP address lookups. Also note that information gained by a trace of a TCP/IP packet through routers would also not be sufficient for these reasons.
I should mention that a perusal of this topic on the web reveals dozens of projects and companies purporting to do just this sort of IP address/domain-based "geolocation" service (based on services such as whois, nslookup, etc., or databases of IP address and domain name ownership potentially provided by Internic, etc.) for use in applications such as location-specific advertising, search engine enhancement, and statistical analyses. For the scope of this midterm, I do not have time to research the topic sufficiently, however it seems to me that because of the reasons I mentioned, as a whole this sort of service is doomed to be limited to a severly low accuracy not to mention precision, especially for use on client users (as opposed to servers, which are the subject of most of the projects I found on the web, and may perhaps be more reliably located geographically close to their owner). This is not to mention that we are talking about a mission critical application such as emergency response. Again, a more constructive, or proactive approach based on higher-level protocols is probably more appropriate, however perhaps combined with a low-accuracy, low-precision (but automatic) backup based on low-level artifacts such as IP address or domain ownership.
My proposal for an Internet 911 system, like many simple and widely compatible Internet-based systems, is run via HTTP, accessible via any web browser. It allows anyone at any computer to access existing local emergency response services like they would on a telephone with 911. It does not require any non-technical support in addition to existing local emergency response services to operate. If you cannot use a telephone for whatever reason, or it would be more convenient to use a computer, you can use this service instead.
Core System - The core system is a web-based application deployed on a robust group of web servers to ensure minimal downtime and "disconnections," and most efficient service. Appropriate load-balancing and associated technologies should be used to ensure robustness. The preference of implementation technologies for the application is not highly important to the goal, so long as they operate via HTTP and achieve the desired robustness. For illustration, let's say we choose PHP. A basic use case scenario would be a user entering the URL of the system in their browser (or choosing a bookmark or clicking on a button in the browser, etc.), then filling a basic HTML form to access local emergency services - either establishing a dialogue or in the minimal case sending a message with information from the form to the emergency response team. The form would include a simple way to enter the following information:
The dialogue could also be a simple form submission and response to ensure compatibility with all browsers, however more sophisticated Java-based applet may be desired for capable browsers. The fundamental core system itself is an extremely simple application basically just accepting form submission and interfacing the other components discussed below.
Location Determination and Local Emergency Response Service Matching - The first requirement in routing the "call" to the appropriate local emergency response service is determination of the location of the "caller," as discussed in the introduction. This problem will be solved on three levels. First, prior to ever needing to use the service, the user will be encouraged to enter full address(es) of all location(s) from which they will use their computer. In most cases (on home PC's), there will be just one address, laptops may entail entering of a home and a work address, for example. These address(es) will be stored on the client side, in cookies, for example. The idea is to have some addresses entered prior to using the service, in order to avoid having to do this during the emergency. The second level is the entry of your address during a "call" - in this case you'd be able to choose your address from a dropdown of previously entered addresses or enter one if necessary. Thirdly, as a backup some use of the IP address/domain name-based lookups discussed in the introduction will be used, however this must be used with discretion and only where appropriate. Once location is determined, the system must match the address with the local emergency response facility just as the existing 911 system does. This will probably be done by somehow integrating with the existing 911 system's matching function, but the details are beyond the scope of this midterm.
Interface to Existing Emergency Response Services - This is the most involved component. Initially, there must be a simple interface via phone and/or fax to local emergency response services. For fax, this would involve faxing the submitted form, for phone it would entail automatic dictation of the submitted form over the telephone. These things are possible with certain existing phone and fax interface components. This would ensure immediate compatibility with all existing local services. Secondly, a means for the dialogue mentioned earlier would be enabled. This would be done by creating another web-based application through which the emergency response personnel at the equipped centers would be able to communicate in real time with the "caller" via a web browser or their current terminals. I do now know enough about the hardware/software currently at emergency response facilities, so I do not know how the integration would take place. I would assume the emergency response personnel would enter and record data manually as usual, but the dialogue would be automatically recorded and stored as the phone calls currently are. The integration of the application into their existing terminals may be a challenge. But again, this is an optional enhancement that may be rolled out progressively only if desired.
Optional Enhanced Features - Given this new simple infrastructure, volumes of "calls" would be running through the system. So, it would be foolish not to enhance the system further in order to capitalize on the situation. The killer feature would of course be to simply record all data related to the "calls" (say in an Oracle database) and to use it for research and data mining applications, not to mention the ability to retrieve such historical information for use in future calls and legal proceedings.
This paper discusses XML query languages and particularly the features or characteristics that the authors believe to be the most important for XML query languages. In order to do this, many example query types are enumerated and an example of each is presented in upto four particular existing query languages. These examples and discussion of them make up the bulk of the paper.
Three of the four example query languages that are used, XML-QL, YATL, and Lorel, arose from designers with a database background. The fourth, XQL, arose from those in the "document" community. The authors, happening to be mostly from the database community, maintain a theme of advocacy for the characteristics of the first three query languages, that are often not even present in XQL. They mention the importance of some of the unique features of the XQL language, however the theme of the paper is clearly based on database-type applications of an XML query language.
The primary key characteristics of the "database query languages" that are enumerated upfront are as follows: 1) three part queries (pattern, filter, and constructor), 2) ordering and nesting constructs, 3) join operator, and 4) tag variables and path expressions.
"Ten essential queries" using an example of XML-encoded information about books, are the main topic. First, a simple "selection and extraction" is discussed (comparable to a simple database select...where), and the basic style of each language is evident - especially the "pattern," "filter," and "constructor" parts. A first shortcoming of XQL is pointed out - the lack of a constructor clause, but for the most part all four languages are sufficient for this task. Second, flattening is discussed - a basis for further restructuring of data. XQL does not support flattening. Third, "preserving structure," or in this case preservation of grouping by book title, is presented. This is natural for XQL. Next, changing structure by nesting and grouping are explored. These are features to present the results of a query in a structure different from that in the original document. Sixth is combining of data sources, or a join operator. By this point the use of variables in the languages is becoming clear. Seventh, indexing is discussed. In the example, sequential numbers are assigned to the authors of books and this is used to present a result data set that includes the first two authors as well as an "et. al." element if there is a third (more than two). A higher level of sophistication in the queries possible in these languages is now clear. Eighth is sorting, or what we know as an "order by" clause. Finally, ninth and tenth are "tag variables" and "regular-path expressions." Tag variables make it possible to deal with XML data of which we do not know the DTD or information about its structure or tags beforehand. Regular-path expressions are used to match certain tag-nesting paths. There is a way to do each of these in the three database query languages, while XQL does not have tag variables, and has a slightly different method for doing path-related functions.
Then, four additional but "less crucial" features are discussed. First, "external functions and aggregation" is required by certain applications. Examples are shown in XML-QL and YATL where minimums or averages are computed. Second, a feature they call "processing of alternatives" - basically an "or" operator for cases such as books having "an author or an editor" - is shown in YATL and XML-QL. Third, the logical "universal quantification" operator, or "for all ..." is shown in Lorel and YATL. Finally, "data models and navigation" is presented and examples in each query language are mentioned.
In the conclusion, the authors reiterate their belief in the importance of basing XML query language design on what we know to be useful and successful in database query languages. This provides "a good compromise between expressive power, simplicity, and performance." They close by mentioning that although they've emphasized the declarativity of the query languages, they are "confident that these features can be evaluated efficiently" because "many well-known optimization techniques exist for the most expensive features described."
The first chapter, "Introduction to WAP," explains that the WAP protocol is the "leading standard" for information services on wireless devices (most commonly mobile phones). WAP makes use of a "Micro Browser," which is basically a very lightweight Internet browser that is suitable to run on current wireless devices. WAP Micro Browsers are able to browse WML documents with optional WMLScript features. As you may guess, WML is a markup language similar to HTML but more lightweight and based on XML, while WMLScript is JavaScript's WAP counterpart - a lightweight scripting language. The current idea for WAP applications are familiar to us today - things such as accessing address or phone number lists and checking weather or flight/train status, sports scores, and stock prices.
The second chapter, "WAP Basics," shows the code for a basic WML page. It looks as you might expect if you are familiar with HTML. However, one theme is unique to WML - WML pages can be thought of as "decks" and are composed of "cards," so you will see many <card> tags in .wml files. The idea is that when accessing a WML page, your wireless unit receives all of the cards in a deck immediately, but views them card by card. Other than that, things like <p> tags are used for paragraphs and <wml> is used to enclose all the WML code, which is primarily just text without data- or CPU-intensive things like complex tables or large graphics.
Next is "WML Formatting," which continues with some basics of the WML language, including tags such as <em>, <br>, <b>, <small>, <big>, and several others that are reminscent of HTML. Very simple tables are also acceptable.
"WML Links and Images" discusses these features. As mentioned, there is a notion of navigating between the cards of a WML page. The <anchor> tag is a more explicit version of <a>, both are acceptable in WML. The <anchor> tag always specifies a task such as "go," "prev," or "refresh," whereas the <a> tag always assumes "go." Also, simple (.wbmp only) images can be placed into a WML page with the <img> tag just as is done with HTML.
FInally, "WML Input" introduces HTML-form-like input features in WML. There is no use of a <form> tag, however <input> tags for text boxes have syntax similar to their HTML counterparts. Additionally, radio buttons and checkboxes are produced with <select> and <option> tags as is done for dropdown menus in HTML. A <fieldset> tag in WML explicitly groups form elements such as textboxes.