Usage Scenarios General Requirements
Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.
136 SVG-Tiny. Similarly, XLS may exist in two profiles that correspond to
different classes of devices. In this case an appropriate capabilities discovery scheme should be devised to allow clients to discover which profiles are
supported by the server
Compatible, Consistent and Extensible
1 XLS should be scalable so that it can support a wide variety of devices, users, and applications.
2 A simple data model should support XLS for all Abstract Data Types. This will minimize the overhead for feature object construction and
deconstruction for OpenLS applications and services. 3 XLS should be defined in XML schema xsd.
4 XLS types should be defined in a way that would give them enough flexibility to be used according to SOAP encoding rules.
5 XLS specification activities should be harmonized with ISO 19133 Navigation, ISO 19118 XML Encoding rules and GML.
6 XLS should be designed so that XLS instances can be transformed e.g., through an XSLT stylesheet into GML.
7 An appropriate versioning scheme should be devised to guarantee clear versioning numbers.
Detailed Requirements General
1 XLS must be based upon well-defined Abstract Data Types for OpenLS. 2 Similar to GML, XLS should maintain the separation between location
information content and presentation. XLS can be directly rendered on the mobile device or through a standard technology like Mobile SVG. Current
parsers for the devices do not have XSLT support.
Encoding
1 XLS must encode the Abstract Data Types for OpenLS in a compact form. The effort to keep the model simple goes hand-in-hand with the need to avoid
the overhead of unnecessary encoding, decoding and feature constructiondeconstruction complexity for users of OpenLS services.
2 XLS should use short tags.
Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.
137 3 XLS may use a minimum tag set that is sufficient to meet the encoding
requirements for the OpenLS Abstract Data Types. 4 XLS may include binary encodings.
5 XLS should avoid multiple levels of nesting. Keep the depth of the trees shallow for simplicity and to minimize the size of code written to handle it.
This helps to keep the applications installed on wireless devices as small in size as possible.
Properties
1 XLS must support the properties required for Abstract Data Types for OpenLS.
2 Properties must be simple properties. Multiple nesting levels should be avoided in properties to avoid complexity.
Metadata
1 XLS should support metadata.
Geometry Elements
1 XLS must include point, line, line-string and polygon geometries, per OGC Simple Feature Model.
2 XLS may include other geometries.
XLS Feature Relationship Schema
1 XLS may use Xlink to reference local resources or remote resources in the same document only, in an appropriate way that would work with the limited
capabilities of available parsers. 2 XLS must support simple relationships in which relationships do not carry
properties.
XLS Feature Schema
1 XLS should support a simplified feature model that doesn’t require multiple nesting levels.
2 XLS must support the Abstract Data Types for OpenLS and related operations.
Copyright © 2002-2008 Open Geospatial Consortium, Inc. All Rights Reserved.
138
Interface Envelop and Encoding Requirements
This section outlines the requirements pertaining to the encoding of the interfaces i.e., the Request and Response Parameters for OpenLS Core Services.