7.5 Manifest
The Manifest describes the contents of the Resource, which could be a payload of the message. This is done by using the Reference object. It makes it possible for recipients to
check the content integrity and to determine whether the contents can be processed before their opening. It also helps with payload extraction. OMF requires a Manifest if there is
any data associated with the message directly or indirectly. The most obvious data is found in the payload direct case, but a Manifest is also required if the message
references data elsewhere through an Internet address indirect case. The Manifest shall be encoded in XML according to the OMF schema detailed below in section 9.
7.6 Reference
The key component in the Manifest is the Reference. If the Manifest exist, it must have a least one Reference. Reference may have zero or more schema associated from which
the payload is defined. It could also provide a text description of the payload. The Reference refers to a URI that could the URI of a payload in the message or a data
resource on the web. This class needs to be extensible to accommodate future needs. More details are given in section 9.
7.7 Schema
The schema provides the data model of a payload. The model can be described using a DTD, XML schema, RDF schema, DAML, Entity-Relation schema. The schema object
gives the internet address where it can be accessed and the version of the schema if needed.
7.8 Error
ErrorList contains a list of Error messages indicate that an error occurred in a previous message. The error is a standard message sent by the OGC message service. Need more
elaboration.
7.9 Acknowledgement
Acknowledgement is a standard message sent by an OGC messaging service and refers to a message by using its identifier MessageID.
7.10 Payload
If a message has a payload container it must have at least one or more payload items. Each payload item must be delineated in some way and must be uniquely identified
within the message’s context.
18
© OGC 2003 – All rights reserved
The OMF Specification makes no provision, nor limits in any way, the structure or content of application payloads. Payloads may be simple-plain-text objects or complex
nested multipart objects. The specification of the structure and composition of payload objects is the prerogative of the organization defining the OGC service processes or
information exchange using the OMF.
TO DO: Need to elaborate on chunked payload
© OGC 2003 – All rights reserved
19
8 Header Element Details
8.1 Message element
8.2 Header element overview
The fragment below defines the normative Header XML Schema.
Normative Header XML schema definition:
20
© OGC 2003 – All rights reserved
element name
= Header
annotation documentation
Encapsulates the OMF header information.
documentation annotation
complexType sequence
element ref
= omf:From
minOccurs =
element ref
= omf:To
minOccurs =
element ref
= omf:MessageId
minOccurs =
element ref
= omf:RefToMessageId
minOccurs =
element ref
= omf:Timestamp
minOccurs =
element ref
= omf:ExpiryTime
minOccurs =
element ref
= omf:Action
element ref
= omf:Manifest
minOccurs =
choice element
ref =
omf:ErrorList minOccurs
= element
ref =
omf:Acknowledgment minOccurs
= element
ref =
omf:StatusRequest minOccurs
= element
ref =
omf:StatusResponse minOccurs
= any
namespace =
other processContents
= lax
minOccurs =
maxOccurs =
unbounded choice
any namespace
= other
processContents =
lax minOccurs
= maxOccurs
= unbounded
sequence attributeGroup
ref =
omf:headerExtension.grp complexType
element
8.2.1 other element
Many Header element children have a other element that allows for foreign namespace-qualified element content to be added for extensibility. The extension element
must be namespace-qualified in accordance with XMLNS [XMLNS] and must belong to a foreign namespace. A foreign namespace is one that is NOT
http:www.opengis.netschemaomf.xsd. The wildcard elements are provided wherever extensions might be required for private or future extension of the framework.
Implementations of the message handler may ignore the namespace-qualified element and its content.
The Header can be used as is, in a message or could be transformed to a specific messaging protocol such as ebXML by using a semantic mapping or a XSLT
transformation. The mechanisms to publish the target messaging framework and transform the normative message to this target messaging framework are out of scope in
this document.
The following diagram illustrates the Header element.
© OGC 2003 – All rights reserved
21
8.2.2 id attribute
Many elements of the header have an id attribute which is an XML ID that may be added to provide for the ability to uniquely identify the element within the header. This may be
used when applying a digital signature to the Message as individual message extension elements can be targeted for inclusion or exclusion by specifying a URI of idvalue
in the Reference element.
8.2.3 version attribute
The Header has a required version attribute indicating the version of the OGC Header Specification. Its purpose is to provide future versioning capabilities. For conformance to
this specification, all of the version attributes on any extension elements defined in this specification must have a value of 1.0. In the future, an OGC message may have a
version value higher than 1.0. An implementation conforming to this specification that
22
© OGC 2003 – All rights reserved
receives a message with a version higher than 1.0 may process the message if it recognizes the version identified and is capable of processing it. It must respond with an
error details TBD if it does not recognize the identified version.
The following sections detail the Header’s children.
8.3 To and From
To and From indicates the sender and receiver of the message. The OGC framework makes these elements optional in the case of synchronous calls such as in HTTP Get. In
the case of asynchronous communication, the To and From are required in order to send back the response at a later time.
Both To and From are of type Actor and are defined as follows:
The Actor is defined by the following XML schema fragment:
© OGC 2003 – All rights reserved
23
Normative PartyId XML schema definition:
element name
=Actor type
=omf:ActorType complexType
name =
ActorType sequence
element ref
= omf:PartyId
maxOccurs =
unbounded element
name =
Role type
= string
minOccurs =
sequence complexType
PartyId is defined as follows:
Normative PartyId XML schema definition:
element name
=PartyId type
=omf:IdentifierType complexType
name =
IdentifierType simpleContent
extension base
= omf:non-empty-string
attribute name
= type
type =
omf:non-empty-string extension
simpleContent complexType
The actor type contains multiple PartyId elements; all members of the list must identify the same Party. Unless a single type value refers to multiple identification systems, the
value of any given type attribute must be unique within the list of PartyId elements contained within either the From or To element. This mechanism is particularly useful
when transport of a message between the parties may involve multiple intermediaries. More generally, the From Party should provide identification in all domains it knows in
support of intermediaries and destinations that may give preference to particular identification systems.
The Actor type contains zero or one Role child element that, if present, shall immediately follow the last PartyId child element. It is recommended to use URI to
define the role. The definition of the role is out of scope in this specification. It could be done for example in a Collaboration Protocol Agreement CPA or in the capabilities of
the service.
Example: The following fragment demonstrates usage of the From and To elements.
24
© OGC 2003 – All rights reserved
omf:From omf:PartyId omf:type=urn:duns123456789omf:PartyId
omf:PartyId omf:type=SCACRDWYomf:PartyId omf:Rolehttp:rosettanet.orgrolesBuyeromf:Role
omf:From omf:To
omf:PartyIdmailto:joeexample.comomf:PartyId omf:Rolehttp:rosettanet.orgrolesSelleromf:Role
omf:To
8.4 MessageId element
Kategori