4.3 Applied Design
4.3.2 Applied Data Encoding: XML Configuration & Pricing Format (XCPF)
The name “XML Configuration & Pricing Format” for the applied data model was chosen to show, that a data set:
• is based on a XML structure
• contains all capabilities for a (geo)-product, which should be configured by customer
• covers the pricing aspect, which is often closely integrated with the configuration.
4.3.2.1 XCPF Object “Product”
This Object is an important structure and is the smallest unit containing a complete calculation environment. This “product” object corresponds via its ID directly to a data product and to its metadata. A “product” object has, in the sense of the XCPF main axis, no child-elements.
Figure 32 XCPF “product” Element
A WPOS instance can use a XCPF price model instance to store order process information into the status list. Each “productGroup” may have a title, but each product must have a title to allow a user a better understanding. An abstract may be used to give some more background information about the product. But the complete product description may be made in an ISO19115 description and referenced by a
“productId”.
The field “transactionNumber“ (TAN) contains an ID, which is needed for the stateless WPOS transactions. There are three ways to implement the workflow for this field:
03.06.2003 1. TAN in the “product” object corresponds to a single ordered product 2. TAN in “productGroup” object corresponds to all entries in an order session 3. TANs in both fields
In the first case, each product data file can be downloaded separately with its own TAN. The second case offers download of compressed data, e.g. a .zip file. Some clients can use the second variant as an accounting mechanism for an ordered shopping cart. The third case offers both possibilities for a user. The tag
“offerDuration” contains a valid timeframe for that offer. Orders can be processed under certain circumstances, which must be declared in a contract object, which is described in 4.3.2.2. The calculation object has the ability to calculate a result.
Roland M. Wagner 4.3.2.2 XCPF Object “contractInformation”
Trade needs agreed rules, which are defined here as contract information. The contact information of the supplier is transparent. The customer’s contact information needs to be added for a valid WPOS “OrderProduct” request. The customer object contains the same entries as for the supplier, but may use more address objects for delivery and accounting.
Figure 33 XCPF object “contactInformation”
03.06.2003 4.3.2.3 XCPF Object “Calculation”
A “calculation” object contains all machine-readable information to determine a price given the configuration input by the user. This object is used in a “product” and in a
“productGroup” environment. Depending on rebates, taxes or other pricing mechanisms, price models can be adjusted with a formula on each hierarchical step of the pricing catalogue.
Figure 34 XCPF object “calculation”
All parameters need to be declared before calculation. Five categories are defined for the processing. Some parameters are necessary for the processing, but are constant, e.g. tax. These parameters can be declared as "predefined". Other parameter values need to be set first by the user.
These parameters are called “configurationParameters”. All these parameters will be visualized in a WPOS client. Some of these may be used for pricing, e.g. Contract time, other may be used for data generation, e.g. style=red and some for both, e.g. data format= dxf.
Referenced parameters can only be used in “productGroup” environments, because they are needed for hierarchical calculations, where parameter values of previous calculated values can be accessed. An often-used example is the sum, wherein previous prices are summarized.
The “precalculatedParameters” are used to store the results of sub functions. These functions may be mathematical operations or XCPF Web Service Calls (XCPF-WSC) and only have values at runtime. The XCPF-WSCs are useful for access to mass storage, for complex calculations or for actual data. They are results of functions.
An often-used example is the calculation of the area of a polygon. The mandatory
Roland M. Wagner
“resultParameters” contains the parameter for the final result of all calculations. All parameters may be used in “functions”. A function has output and input parameters and delivers a result value. The possible operation types are described in the next section.
4.3.2.4 XCPF Object “parameter”
The parameter object is the basic element for each calculation. Each parameter must have a logical name and for language reasons, one or more different descriptions.
Spaces are allowed in the description.
Parameters can be arranged in groups by using the optional “variableGroup” element.
A group of parameters is declared with identical strings in the “variableGroup” field.
An example is the use of a set of parameters for data generation. All parameters must contain the same string in the “variableGroup”, e.g. "geoserver". All the parameters, and their values with the same string, may be filtered and transferred as output parameters to the geo-data generation server.
Figure 35 XCPF “object parameter”
The element “variableOrigin” must only be used in the "referencedParameters" object, which occur in “productGroups”. The hierarchical calculation process (see 4.2.2.4) uses parameters with “variableOrigin” elements to access other parameter values from a lower level. The required attribute "orginName" contains the original name of a low hierarchical parameter. A reference is only allowed to the next following level.
Referenced parameters can be used in two ways as:
• Multiple references, returning a list of parameter values
• Single references, returning a single value
An often-used multiple-reference example is the price calculation from a lower level to the higher level, which refers to the list of all price results from the lower level. Multiple references must have the character ”*” as a wildcard in the element “originId”, to access all parameter values with the same name, not depending on product entries.
Single references must have the productId of the referenced product in the lower level.
A reference to a “product” object on the same level is not allowed.
03.06.2003 4.3.2.5 XCPF Object “operation”
There are two possible operations to achieve results with a list of output and input parameters: mathematical formulae and external XCPF Web Service Calls (XCPF WSC).
Figure 36 XCPF object operation
The mathematical formulae are encoded by using a subset of the Mathematical Mark-up Language (MathML) definition, recommended by the WWW-Consortium (W3C) (Carlisle, Ion, Miner, Poppelier, 2001). XCPF uses only basic operations, like plus, minus,
Roland M. Wagner min and other (see Figure 36). Source 20 and Source 21 give an example of the
formula encoding with MathML.
Source 20 price = pricePerSquareKilometer * surface
<math>
<apply>
<eq/>
<ci>price</ci>
<apply>
<times/>
<ci>pricePerSquareKilometer</ci>
<ci>surface</ci>
</apply>
</apply>
</math>
Source 21 Encoding of formulae with MathML
The other possible operation is a XCPF Web Service Call. The element
“OnlineResource” contains an absolute URL to a web service for external processing.
4.3.2.6 XCPF Object “productGroup”
With the use of these elements, “product” objects can be arranged into groups. The
“productGroup” element contains almost the same elements as the “product” object.
Therefore it is even possible to have some pricing calculations on product group level.
This is required to price product constellations (see 3.1.4 use-case and 3.2.2 analysis).
But it can also contain an “inheritance” object and one or more “product” objects. A
“productGroup” can contain one or more other “productGroup” objects.
Figure 37 XCPF Object “productGroup”
03.06.2003 4.3.2.7 XCPF Object “Inheritance”
The inheritance method provides an optimisation mechanism for large data entries. The
“inheritance” object contains all elements that are allowed in the “product” and
“productGroup” elements. Typical examples of inheritance are the contract information and calculation blocks. Inheritance can be overwritten in following
“productGroups” or “products” as described in 4.2.2.5.
Figure 38 XCPF object “inheritance”
Roland M. Wagner 4.3.2.8 Main structure axes
The main axes in XCPF are “xcpfEnvelope”, “xcpfCatalog”, multiple “productGroup”
objects and finally products (see 4.2.2.3).
Figure 39 XCPF main axis
03.06.2003