Using COLLECT to 'bulletinize' IWXXM messages

The COLLECT-XML(*1) is developed to represent a collection of GML feature instances of the same type of meteorological information(*2).  The intent is to allow XML encoded meteorological information to be aggregated in a way that emulates the existing data distribution practices used within the WMO Information System (WIS) and AFS.  In addition to the XML schema, schematron rules are also in place to validate conformance of aggregated IWXXM messages to COLLECT-XML requirements.  The bulletin can either be sent directly, or as a compressed file, as attachment via AMHS Extended Services.  The following is an example of a bulletin of IWXXM METAR messages aggregated with COLLECT-XML and its corresponding TAC bulletin.

<?xml version="1.0" encoding="UTF-8"?>
   <collect:MeteorologicalBulletin gml:id="LAHK31VHHH-201511020800">
    <collect:meteorologicalInformation>
        <iwxxm:METAR gml:id="metar-VHHH-201511020800">
            ...
        </iwxxm:METAR>
     </collect:meteorologicalInformation>
     <collect:meteorologicalInformation>
        <iwxxm:METAR gml:id="metar-RCTP-201511020800">
            ...
        </iwxxm:METAR>
     </collect:meteorologicalInformation>
     <collect:meteorologicalInformation>
        <iwxxm:METAR gml:id="metar-RCHK-201511020800">
            ...
        </iwxxm:METAR>
     </collect:meteorologicalInformation>
     <collect:meteorologicalInformation>
        <iwxxm:METAR gml:id="metar-RCSS-201511020800">
            ...
        </iwxxm:METAR>
     </collect:meteorologicalInformation>
        ...
   <collect:bulletinIdentifier>
      A_LAHK31VHHH020800_C_VHHH_201511020800--.xml
   </collect:bulletinIdentifier>
   </collect:MeteorologicalBulletin> 

SAHK31 VHHH 020800
METAR VHHH 020800Z 34011KT CAVOK 24/14 Q1018 NOSIG=
METAR RCTP 020800Z 05017KT 5000 BR FEW010 SCT016 BKN025 19/16Q1021 NOSIG RMK A3015=
METAR RCKH 020800Z 34006KT 310V020 9999 FEW016 BKN045 BKN060 27/22Q1016 NOSIG RMK A3001=
METAR RCSS 020800Z 12009KT 4500 BR FEW008 BKN018 OVC035 20/17Q1021 NOSIG RMK A3015=
METAR RCMQ 020800Z 02017G28KT 9999 FEW012 BKN150 20/16 Q1017 NOSIGRMK A3004=
METAR RCNN 020800Z 33010KT 9999 FEW012 SCT025 BKN080 26/20 Q1016NOSIG RMK A3001=
METAR VMMC 020800Z 36014KT 9999 FEW045 23/15 Q1018 NOSIG=
METAR RPLL 020800Z 12008KT 040V170 9999 VCSH FEW023CB SCT025 SCT090BKN300 30/23 Q1010
      NOSIG RMK A2983 CB NW PCPN DSTN W-N=
METAR RPVM 020800Z 04005KT 9999 FEW020 BKN100 29/24 Q1010 A2984 CBDSPTD=
METAR RPMD 020800Z NIL=
METAR RPLB 020800Z 06005KT 9999 FEW020 BKN080 29/22 Q1010 A2983NOSIG=
METAR RPLI 020800Z 34002KT 9999 FEW019 32/23 Q1009 NOSIG RMK A2980=
METAR RPMZ 020800Z NIL=
NNNN

Use of WMO AHL to identify the bulletin

Currently there is only one element “collect:bulletinIdentifier” in COLLECT-XML to identify the bulletin.  It is an alphanumeric string conforming to a special convention of the WMO AHL(*3)(*4).  While the metadata in a WMO AHL may be enough for exchanging TAC bulletins, more sophisticated representation of the metadata will be required for identification, exchange and processing of IWXXM bulletins.  For example, The Guidelines for the Implementation of OPMET Data Exchange using IWXXM suggests the inclusion of metadata of the aggregation centre (Assumption 9), which may be different from the originating or compiling station mentioned in CCCC of the WMO AHL, in creating a bulletin.

Choice of gml:id

Special attention is also required to ensure successful aggregation of IWXXM messages at national or international data aggregators.  This is due to the fact that all “gml:id”s defined within an XML/GML instance should be unique.  As IWXXM messages are prepared by different originators, a set of common rules for the generation of “gml:id” is essential to ensure smooth aggregation of IWXXM messages from different originators.

In the example above, the "gml:id"s are defined in accordance to some rule sets in relation to the characteristics of the report.  Another choice is to use UUID (Note: "gml:id" requires a string starting with a letter) like gml:id="uuid.bfefd061-8a4b-4cf2-b5fd-9ba3db93e276".  While both look good for sub-regional, regional or global exchanges, experience seems to imply that using UUID in gml:id is the best practice so far.