Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.
139
XML Encoding App
Servlet
OpenLS Core Services
Web Server
XML Decoding App
Pr e
s e
n ta
ti o
n
Wireless to IP Gateway
Client Application
HTTPPost XML Request
XML Response
getService p1, p2, pn
Figure 9. Usage Pattern for OpenLS RequestResponse Pairs 1.3.3 Assumptions
1 The architecture is based on connectionless protocol. A Client Application may establish a connection for making a Request, and disconnect right after a
Response has arrived. 2 The Client Application knows the Request URI for the OpenLS Core Service.
This includes the Port Number. 3 Client Applications are aware of all Interfaces that the Core Service exposes.
4 The Core Service can parse and understand the semantics of the XML Request Parameters generated by the Client Application.
5 Core Services know all the mandatory and optional Request Parameters generated by Client Applications.
6 Client Applications can parse and understand the semantics of the XML Response Parameters generated by Core Services.
7 Client Applications know all mandatory Response Parameters, and possibly some, all, or none of the optional Response Parameters generated by Core Services. If an
optional parameter is sent to a Client Application, it is then assumed that the Client Application can understand it; otherwise the Client Application generates
an error message or ignores this optional Response Parameter.
1.3.4 General Requirements
The following requirements pertain to both Request and Response Schemas:
Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.
140
1 The RR schemas must be based on XML Schema, re: W3C Recommendation 2
May 2001.
2 Encoded ADT-based RR Parameters in XML must be consistent with the
encoding guidelines and requirements as stipulated in the latest version of the XML for Location Services XLS Requirements section 0.
3 RR pairs must be consistent with the XLS ADTs. 4 RR Pairs must be Well-Known Types.
5 Upon receiving a Request from a Client Application, a Core Service must send at
least one Well-Known Response to the Client Application. A Response might be an answer to the Request, an error message, or an acknowledgement of receiving
the Request.
6 XML RR instances must be well formed and valid with respect to their schemas.
1.3.5 Encoding Requirements 1.3.5.1 Naming
1 If applicable, you should satisfy encoding name conventions as stipulated in the
latest version of the XML for Location Services XLS Requirements section 0.
2 You should use English descriptors that accurately describe the
attributeelementtype, etc. For example, use names like firstName, grandTotal, or CorporateCustomer. Although names like x1, y1, or fn are easy to type because
they’re short, they do not provide any indication of what they represent and result in schemas that are difficult to understand, maintain, and enhance.
3 Be consistent in using terminology. You should use terminology that applies for
the application domain. For example, if you create an element MobileDevice and the mobile operators call it MobileTerminal, use the latter.
4 You should use avoid long names. Some standards recommend a maximum of 13
characters and some 15 characters. For OpenLS, try to limit names to 15 characters in length.
5 Do your best to avoid the use of abbreviations. If you must use an abbreviation, then be consistent with its use. For example, if you want to use a short form for
the word “number”, then you should use something like ‘nbr’ or ‘num’ it doesn’t really matter what form you use, but be consistent in its use.
6 You should avoid names that are similar or differ only in case. For example Name
and name. This aids interpretability of the schema.
