Preview. Built from the published NewsML-G2 documents by tools/prosedoc. This layout is a harness for reviewing structure — it is not the published site.
16. Exchanging News: News Messages
16.1. Introduction
News communication is often by means of a provider’s broadcast or multicast feed, with transactions carried out by a separate sub-system that has its own specific identification and transmission methods, independent of NewsML-G2.
The News Message (<newsMessage>) facilitates these transactions, enabling the exchange of any number of NewsML-G2 Items by any kind of digital transmission system.
The use of <newsMessage> is entirely optional: items may also be exchanged using SOAP, Atom Publishing Protocol (APP) or other suitable content syndication method.
News Messages are a convenient wrapper when sending a Package Item and all of its referenced content in a single transaction (but note that it is not necessary to send packages and associated content together in this manner).
The News Message properties are transient; they do not have to be permanently stored, although it may be useful if transmission/reception records are maintained, at least for a limited period during which requests for re-sending of messages may be made. If the content items carried by the message have a dependency on news message information, this information should be stored with the items themselves.
16.2. Structure
A diagram of the structure of a News Message and its payload of Items is shown below.
A News Message MUST have a <header> component, which MUST contain a <sent> transmission timestamp. These are the only mandatory requirements.
The News Message payload is the <itemSet> component, which may have an unbounded number of child <newsItem>, <packageItem>, <conceptItem> and <knowledgeItem> components in any combination and in any order.
16.2.1. News Message Header <header>
The Header contains a set of properties useful for managing the transmission and reception of news. The simple implementation of News Message uses elements with string values, e.g.
<sender>reuters.com</sender>
Optionally, providers can use more semantically defined values for header properties, either using URI, QCode or literal values, and also use other QCode type properties to add further detailed information, e.g.:
<sender qcode="ex-sndr:rtr">reuters.com</sender>
or
<sender literal="reuters">reuters.com</sender>
If using controlled values for properties of the News Message, providers should note the following conditions:
-
If QCode values are used: either a <catalog> or a <catalogRef> child elements of <header> MUST be present to provide the required Scheme URIs of the controlled vocabularies used. (see Creating and Managing Catalogs for details) The scope of the <header> catalog is limited to the News Message header only, and is NOT inherited by any of the Items under <itemSet>.
-
If a @literal attribute is used together with a string value for a property: the value of the @literal and of the string should be identical (as in the second example of <sender> above); if not, then the value of @literal takes precedence.
| <catalog> or <catalogRef> are optional for News Messages, but mandatory for Items. |
The child elements of <header> that may use qualifying attributes are:
-
sender
-
origin
-
channel
-
destination
-
timestamp (optional @role, see below)
-
signal (may use @qcode only)
The following qualifying attributes are defined:
| Name | Cardinality | Datatype | Definition |
|---|---|---|---|
qcode |
0..1 |
QCodeType |
A qualified code assigned as a property value. |
uri |
0..1 |
XML Schema anyURI |
A URI which identifies a concept. |
literal |
0..1 |
XML Schema normalizedString |
A free-text value assigned as a property value. |
type |
0..1 |
QCodeType |
The type of the concept assigned as a controlled or an uncontrolled property value. |
role |
0..1 |
QCodeType |
A refinement of the semantics of the property. |
Both string values of properties and the use of qualifying attributes are given as examples below. Note that unless stated otherwise, the scheme aliases used in QCode type properties are fictional.
Sent timestamp <sent>
Mandatory, non-repeatable. The transmission timestamp is in ISO8601 format. Note that if a news message is re-transmitted, the sender is NOT required to update this property.
<sent>2025-10-19T11:17:00.100Z</sent>
Catalog <catalog>
An optional reference to the Scheme URI of a Controlled Vocabulary to enable the resolution of QCode values of properties used in the document:
<catalog>
<scheme alias="nmsig" uri="http://cv.example.com/newscodes/newsmsgsignal/" />
</catalog>
Remote Catalog <catalogRef>
An optional reference to a remote catalog containing one or more scheme URIs for the CVs used in the document:
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
Message Sender <sender>
An optional, non-repeatable string. Best practice is to identify the sender (not necessarily the same as the provider in <itemMeta>) by domain name:
<sender>reuters.com</sender>
Transmission ID <transmitId>
An optional, non-repeatable string identifying the news message. The ID must be unique for every message on a given calendar day, except that if a message is re-transmitted, it may keep the same ID. The structure of the string is not specified by the IPTC.
<transmitId>tag:reuters.com,2016:newsml_OVE48850O-PKG</transmitId>
Priority <priority>
Optional, non-repeatable. The sender’s indication of the message’s priority, restricted to the values 1-9 (inclusive), where 1 is the highest priority and 9 is the lowest. Priority would be used by a transmission system to determine the order in which a message is transmitted, relative to others in a queue. Urgency is an editorial judgement expressing the relative news value of an item.
<priority>4</priority>
Note that message Priority is not the same as the <urgency> of an individual Item within the news message, although they may be correlated. A typical example is that the Priority may be set to the highest Urgency value associated with any of the Items carried by the message.
Message Origin <origin>
An optional, non-repeatable string whose structure is not specified by the IPTC. It could denote the name of a channel, system or service, for example.
<origin>MMS_3</origin>
or
<origin qcode="nmorgn:mms3 />
Channel Identifier <channel>
An optional, repeatable string that gives the partners in news exchanges the ability to manage the content, for example as part of a permissions or routing scheme. The notion of a channel has its origins in multiplexed systems, but may be an analogy for a product – a virtual <channel> delivered within a physical stream identified by <destination>.
<channel>email</channel>
or
<channel qcode="ex-nmchan:smtp" />
Destination <destination>
An optional, repeatable, destination for the news message, using a provider-specific syntax. In broadcast delivery systems, this may be one or more physical delivery points:
<destination>foo.bar@example.com</destination>
or
<destination role="ex-nmdest:foobar">UKI</destination>
Timestamps <timestamp>
An optional and repeatable <timestamp> property may be used to indicate the date-time that a <newsMessage> was received and/or transmitted. The values must be expressed as a date-time with time zone. The property may be refined using the optional @role, which may be a literal or QCode value, but note that if using a QCode the string that should be interpreted as a QCode MUST be defined outside the NewsML-G2 specification by the provider of the News Message:
<timestamp role="received">2025-10-18T11:17:00.000Z</timestamp>
<timestamp role="transmitted">2025-10-19T11:17:00.100Z</timestamp>
Signal <signal>
Optional, repeatable; the <signal> element can be used to indicate any special handling instruction to the receiver’s NewsML-G2 processor:
<signal qcode="nmsig:atomic" />
There is a recommended IPTC News Message Signal NewsCodes CV with a Scheme URI of: http://cv.iptc.org/newscodes/newsmsgsignal/
The recommended scheme alias is "nmsig" and there is currently one member of the CV: "atomic" which signals to the receiving processor that the content of the News Message should be processed together. This enables providers to indicate that a Package Item and all of the Items that are referenced by that Package should be processed as a single "atomic" (i.e. indivisible) bundle.
16.2.2. News Message payload <itemSet>
Each <newsMessage> MUST have one <itemSet> component, which wraps the NewsML-G2 Items that are to be transmitted.
The contents of <itemSet> can be "any" component or property from the NAR namespace. This is to enable schema-based validation of the content of the Items in the message.
The IPTC recommends that the child elements of <itemSet> be any number of <newsItem>, <packageItem>, <conceptItem>, and/or <knowledgeItem> components, in any combination, in any order.
The listing below shows a "skeleton" News Message containing a Package Item that references four News Items, together with the referenced items themselves, as an "atomic" package, with some of the <header> properties using a QCode value, which requires a reference to a Catalog (in this case two Remote Catalogs referenced using <catalogRef>).
QCodes used in listing below are from IPTC NewsCodes vocabularies, except for ex-nmdest.
<?xml version="1.0" encoding="UTF-8"?>
<newsMessage
xmlns="http://iptc.org/std/nar/2006-10-01/">
<header>
<sent>2025-10-19T11:17:00.150Z</sent>
<catalogRef href="http://www.example.com/std/catalog/NewsNessages_1.xml" />
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
<sender>thomsonreuters.com</sender>
<transmitId>tag:reuters.com,2016:newsml_OVE48850O-PKG</transmitId>
<priority>4</priority>
<origin>MMS_3</origin>
<destination role="ex-nmdest:foobar">UKI</destination>
<channel>TVS</channel>
<channel>TTT</channel>
<channel>WWW</channel>
<timestamp role="received">2025-10-19T11:17:00.000Z</timestamp>
<timestamp role="transmitted">2025-10-19T11:17:00.100Z</timestamp>
<signal qcode="nmsig:atomic" />
</header>
<itemSet>
<packageItem>
<itemRef residref="N1" />
<itemRef residref="N2" />
<itemRef residref="N3" />
<itemRef residref="N4" />
</packageItem>
<newsItem guid="N1"> ..... </newsItem>
<newsItem guid="N2"> ..... </newsItem>
<newsItem guid="N3"> ..... </newsItem>
<newsItem guid="N4"> ..... </newsItem>
</itemSet>
</newsMessage>