Profil canadien du Protocole d'alerte commun (PC-PAC) Introduction au PC-PAC et ensemble de règles Beta 0.4

Profil canadien du Protocole d'alerte commun (PC-PAC) Introduction au PC-PAC et ensemble de règles Beta 0.4 Version PDF (977 Ko)

Objet du document

Le présent document décrit, à l’intention des intervenants canadiens des alertes au public, le Profil canadien du Protocole d’alerte commun (PC-PAC). Ce profil décrit un ensemble de règles et de listes gérées de valeurs, dont l’utilisation est recommandée au Canada dans les systèmes d’alerte au public. Ce document aborde l’ensemble de règles du PC-PAC.

Ce profil est conforme au Protocole d’alerte commun, (la « norme de référence » ou PAC), puisqu’un PC-PAC valide englobe aussi un PAC valide. Comme dans la norme de référence, la conformité au PC-PAC n’est pas limitée à une méthodologie d’alerte en particulier, et elle n’est pas non plus propre à une méthode d’alerte, une voie de communication ou un sous-groupe d’intervenants dans le domaine des alertes au public. En fait, des efforts importants ont été déployés pour éviter de privilégier une méthode, une voie ou un sous-groupe d’intervenants.

Auteurs

Voici la liste alphabétique des principaux auteurs de la version du document :

• Doug Allport, Association canadienne d’avis et d’alerte au public/Allport Group Inc.
• Rémy Bernard, Sécurité publique Canada
• April Diver, Alberta Emergency Management Agency
• Khalil Hayek, Ressources naturelles Canada
• Norm Paulsen, Environnement Canada
• Michel Savoie, Sécurité publique Canada
• Jacob Westfall, Net Alerts
• Wendy Wu, Industrie Canada

Droits d’auteur

Droits d’auteur 2010. Ce document peut être reproduit, sans frais ou demande de permission, à condition qu’il soit reproduit dans son ensemble et sans modification.

Avis

Ce document et l'information qu'il contient sont présentés sur une base ''TEL QUEL'' et les auteurs, leurs officiers, employés ou agents DÉSAVOUENT TOUTE GARANTIE OU REPRÉSENTATION, EXPRESSE OU IMPLICITE, INCLUANT MAIS PAS LIMITÉ À TOUTE GARANTIE OU REPRÉSENTATION QUE L'UTILISATION DE CETTE INFORMATION N'ENPIÉTERA PAS LES DROITS DES AUTRES, OU TOUTE GARANTIE OU REPRÉSENTATION IMPLICITE DE COMMERCIALISATION OU D'UTILITÉ POUR UN BUT SPÉCIFIQUE.

Sommaire des révisions

Le présent document comprend les révisions majeures apportées au document Beta 0.3 :

1. Mis à jour pour utiliser la version 1.2 du PAC
2. Suppression de la règle n^o 4 (règle des fuseaux horaires) vu que le PAC 1.2 l’intègre maintenant
3. Ajout à la règle no 18, en ce qui a trait au traitement de l’élément <area>
4. Ajout d’une section intitulée « Au sujet des couches »
5. Clarification concernant les pièces jointes et ressources répondant au besoin du libellé de la règle no 6.

Autres documents PC-PAC

Le PC-PAC au complet est défini dans le présent document et les deux documents indiqués ci-dessous.

1. Lexique des événements du PC-PAC. Ce document précise une liste compréhensive d’événements associés avec les alertes publiques au Canada.
2. Lexique des localisations du PC-PAC: Ce document décrit les versions actuelles des références de localisation de la Classification géographique type (CGT) appuyées par le PC PAC. Le contrôle des versions est assuré indépendamment du présent document.

Afin d’assurer l’accès au PC-PAC par les intervenants des alertes au public aussi vite que possible, les trois documents du PC-PAC sont disponibles sur les sites Web suivants :

• Association canadienne d’avis et d’alerte au public (ACAAP) - www.CAPAN.ca/CAP-CP
• Environnement Canada – à confirmer
• Industrie Canada - http://www.ic.gc.ca/eic/site/et-tdu.nsf/fra/wj00268.html
• Ressources naturelles Canada - à confirmer
• Sécurité publique Canada – à confirmer
• Alberta Emergency Management Agency - http://www.aema.alberta.ca/ps_emergency_public_warning_system.cfm

Le PC-PAC peut également se retrouver sur d’autres sites Web. Si des différences existent entre les versions, la version au www.CAPAN.ca/CAP-CP aura la priorité. Des nouvelles versions seront créées seulement avec la permission expresse du Groupe de travail sur le PC-PAC.

Documents et ressources connexes

1. Le Protocole d’alerte commun (PAC) version 1.2 est une norme administrée par Organization for the Advancement of Structured Information Standards (OASIS). La norme est disponible sur le site Web suivant: http://docs.oasis-open.org/emergency/cap/v1.2/
2. www.CAPAN.ca/CAP-CP. Le site Web du PC-PAC identifie plusieurs ressources reliées au PC-PAC.

Terminologie

Les mots « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « FACULTATIF », employés dans le présent document, doivent être interprétés conformément à la description de la demande de commentaires 2119 de l’IETF, accessible au http://www.ietf.org/rfc/rfc2119.txt (en anglais seulement).

Le PC-PAC adopte aussi la terminologie de la norme de référence. De plus,

Le terme « couche » (layer) est utilisé dans le présent document pour désigner les éléments de message qui ne sont pas nécessaires en vertu de la norme de référence ou du PC-PAC, mais qui peuvent se rapporter à une nouvelle règle, à d’autres listes gérées et/ou à de l’information propre à un sous-ensemble d’utilisateurs de la communauté des alertes au public du Canada. Une couche est habituellement soutenue par l’utilisation d’au moins un élément <parameter> dans un fichier du PAC ou du PC-PAC. Footnote1

L’expression « liste gérée » est employée dans le présent document pour désigner une série de valeurs permises se rapportant à un élément donné d’un message PC-PAC (par exemple, la liste des événements du PC-PAC). La liste collective des valeurs est gérée à l’aide des versions continues vu que la liste est susceptible de changer pour tenir compte des besoins de la communauté des utilisateurs.

Le terme « profil » est utilisé dans le présent document pour désigner un ensemble de règles, de listes gérées et d’autres références, qui se rapportent à la norme de référence. Un profil est considéré comme nécessaire pour répondre aux besoins propres à un pays ou à un système qui utilise norme de référence, et pour la communauté complète d’utilisateurs qui s’identifient au profil. Un profil fournit le contexte nécessaire pour l’activité d’alerte au sein d’un pays ou système.

L’expression « ensemble de règles » est employée dans le présent document pour désigner un ensemble de règles qui s’appliquent à l’utilisation de la norme de référence, qui imposent des exigences à l’égard de l’utilisation au-delà de la norme de référence, mais qui demeurent aussi conformes à la norme de référence.

Développement du PC-PAC comme norme nationale du Canada

Les auteurs de la présente version PC-PAC envisagent de soumettre le profil à un organisme canadien d’élaboration de normes pour développement comme norme nationale du Canada. Ceci, ils anticipent, assurera un processus reconnu dans les décisions concernant les éléments de la norme sur une base initiale ainsi qu’à long terme et assurera également la clarté et l’accès à la norme par tous les intervenants en alertes au public. Avec l’initiation formelle du processus de développement de la norme, l’organisme d’élaboration de normes deviendra le gardien et administrateur de PC-PAC.

Introduction

Historique du PAC

La nécessité d’établir un protocole d’alerte au public a fait surface dans un rapport intitulé Effective Disaster Warnings, publié en 2000 par le National Science and Technology Council des États-Unis. Le rapport concluait qu’une méthode normalisée devrait être élaborée pour compiler et transmettre instantanément et automatiquement tous les types d’avertissements et de signalements de danger à l’échelle locale, régionale et nationale en vue de saisir les données dans un large éventail de systèmes de diffusion.

M. Art Botterell, un représentant des communications publiques de l’état de la Californie, a proposé ce qu’on connaît maintenant sous le nom de Protocole d’alerte commun (PAC). Les efforts de M. Botterell, conjugués au soutien d’une vaste communauté d’intervenants, ont abouti à l’homologation du PAC, ainsi qu’à l’aide financière du Partnership for Public Warning^{Footnote 2} (PPW) des É.-U.

En 2004, le PAC est devenu une norme de l’Organization for the Advancement of Structured Information Standards (OASIS), et a été subséquemment adoptée par l’Union internationale des télécommunications (UIT).

Les besoins du Canada

À l’automne 2002, Industrie Canada a lancé une initiative d’alerte au public afin d’étudier les lacunes et d’évaluer les nouvelles technologies d’alerte au public au Canada. Industrie Canada a suivi l’élaboration du PAC aux É.-U. et reconnu ses avantages pour les systèmes canadiens d’alerte au public. Le 1er mars 2005, Industrie Canada a organisé un Forum et atelier sur l'alerte au public et présenté une vision de l’alerte au public au Canada. La vision a amené l’adoption du PAC comme norme nord-américaine.

Peu après, l’Organisation des mesures d'urgence du Nouveau-Brunswick (OMUNB) et Allport Group ont indiqué que les intervenants canadiens de l’alerte au public avaient besoin d’un profil propre à la mise en œuvre du PAC au Canada. Ils ont présenté une exigence à l’égard du soutien des considérations linguistiques et géopolitiques.

Industrie Canada a fourni des fonds pour le développement d’une version canadienne du PAC en partenariat avec l’OMUNB. Industrie Canada a également organisé un atelier multilatéral national en 2006 pour discuter de la mise en œuvre canadienne. Cet atelier a donné lieu à un groupe de travail du PAC, qui a été mis sur pied par Industrie Canada et qui a rédigé un profil canadien provisoire en date du 27 juillet 2007 (ébauche 1). Ce document a été mis à jour le 8 mai 2008 (ébauche 2).

Les premières personnes à mettre en œuvre le PC-PAC ont décelé quelques problèmes avec l’ébauche du 8 mai 2008 du PC-PAC. À l’automne 2008, Environnement Canada (EC) a présidé une série de réunions, auxquelles ont participé des représentants du gouvernement au niveau fédéral et provincial et un échantillon représentatif d’organisations connexes touchées de l’industrie. Par conséquent, des modifications ont été apportées à l’ébauche no 2 (8 mai 2008).

Environnement Canada a également créé un processus de mise en œuvre des références du PC-PAC, afin de diriger la discussion sur l’interprétation du PAC et du PC-PAC au Canada. Cette procédure de mise en œuvre se compose d’un site web hébergé par Environnement Canada offrant des exemples en temps réels et statiques de PAC et PC-PAC à des buts de contrôle de qualité. Cette procédure de mise en œuvre des références aidera les intervenants à comprendre les différences d’interprétation et devrait améliorer, dans l’ensemble, l’intégrité de chacun des systèmes visés.

Au sujet des couches

Comme il est défini ci-dessus, le terme couche utilisé dans le présent document pour désigner les éléments de message qui ne sont pas nécessaires en vertu de la norme de référence ou du PC-PAC, mais qui peuvent se rapporter à une nouvelle règle, à d’autres listes gérées et/ou à de l’information propre à un sous-ensemble d’utilisateurs de la communauté des alertes au public du Canada. Une couche est habituellement soutenue par l’utilisation d’au moins un élément <parameter> dans un fichier du PAC ou du PC-PAC.^{Footnote 3}

Aperçu du PC-PAC

Le PC-PAC est axé surtout sur quatre principales exigences et contraintes, soit :

1. Contrainte d’un type d’événement par message d’alerte
2. Exigences linguistiques
3. Exigences associées à la détermination des événements
4. Exigences associées à la détermination des localisations

De plus, il existe d’autres règles et recommandations pour aider les utilisateurs à surmonter les difficultés associées à la mise en œuvre qui ont été décelées par les premières personnes à adopter la norme de référence.

Les particularités de tous ces éléments sont décrites plus loin dans le document. Les lignes qui suivent présentent une analyse générale de chaque point.

1.     Contrainte d'un événement par fichier d'alerte.

La norme de référence permet l’inclusion de plusieurs événements dans un seul message d’alerte, mais elle précise qu’un seul identificateur unique de message est nécessaire. Par conséquent, la mise à jour d’un des événements apparaîtrait comme une mise à jour de tous les autres événements du même message d’alerte, même s’il n’y a aucun changement à signaler pour les autres événements.

De plus, étant donné que les valeurs des événements seront utilisées à des fins de filtrage, d’acheminement, de validation et d’autres besoins au sein de la communauté, les systèmes auraient du mal à traiter un message d’alerte unique qui contiendrait de nombreux événements, où tous les événements pourraient sembler avoir été mis à jour alors que ce n’est pas nécessairement le cas.

Pour éviter toute confusion, le PC-PAC limite chaque message d’alerte du PAC à un seul événement.

2.     Exigences linguistiques

La norme de référence indique une valeur linguistique comme un élément facultatif. En l’absence d’une valeur, l’anglais des États-Unis est la valeur utilisée par défaut, conformément à la norme de référence. Au Canada, où il y a deux langues officielles, l’utilisation de la valeur linguistique est très importante pour les distributeurs de messages.

Le PC-PAC rend obligatoire l’utilisation de la valeur linguistique. De plus, il définit des pratiques supplémentaires qui permettent de surmonter les difficultés associées à l’envoi et à la mise à jour d’alertes dans plusieurs langues.

3.     Exigences associées à la détermination des événements

La norme de référence exige seulement la présence d’une valeur pouvant être lue par l’humain décrivant l’événement en question  pour un message d’alerte. Elle n’offre pas de suggestion ou de liste reconnue d’événements, puisque c’est le rôle de tous les systèmes d’alerte qui utilisent la norme de référence.

Toutefois, étant donné que le PC-PAC comprend des règles sur des questions telles que les langues, la prestation d’une liste coordonnée d’événements canadiens intégrée au PC-PAC, indépendamment de tout système d’alerte précis, assurera une certaine uniformité pour le public canadien.

Étant donné que bien des alertes canadiennes seront traduites par des applications automatisées, il faut établir une liste d’événements reconnus pré-traduits. En outre, l’utilisation d’une liste de contrôle facilite la transmission de tous les niveaux d’alertes au public selon le type. Le PC-PAC exige un code d’événement, qui provient d’une liste gérée exhaustive des événements. Comme susmentionné, cette liste est gérée séparément des règles du PC-PAC, puisqu’on s’attend à ce qu’elle soit modifiée plus souvent que les règles.

4.     Exigences associées à la détermination des emplacements

La norme de référence permet d’utiliser des codes de localisation géoréférencés pour identifier la ou les régions touchées par une alerte. Toutefois, les exigences minimales du PC-PAC sont les suivantes : la description textuelle de la région et les codes de localisation géoréférencés doivent être utilisés pour les localisations au Canada, et ils doivent correspondre aux régions géopolitiques reconnues. Les régions géopolitiques sont faciles à repérer dans la plupart des cartes et sont considérées comme le meilleur dénominateur commun pour associer les alertes à des localisations reconnaissables pour la population canadienne. La Classification géographique type (CGT) de Statistique Canada est la liste de référence du PC-PAC pour les codes de localisation géopolitiques. Le système de la CGT fournit des codes numériques uniques pour trois types de régions géographiques : provinces et territoires; divisions de recensement (DR), comme les comtés et les municipalités régionales; et subdivisions du recensement (SDR), comme les villes, les villages et les cantons. Pour de plus amples renseignements sur la CGT de 2006, visitez le
http://www.statcan.gc.ca/subjects-sujets/standard-norme/sgc-cgt/2006/2006-ind-fra.htm

Le Lexique des localisations du PC-PAC indique la version (ou les versions) de la CGT dont l’utilisation est actuellement reconnue et fournit des renseignements sur l’utilisation de la CGT dans le PC-PAC, ainsi que certaines des limites de la CGT en ce qui concerne les noms de lieux dans plus d’une langue.

Au moment de la rédaction, la plupart des codes de la CGT comprennent un renvoi à un seul nom unique dans une langue officielle (la langue couramment utilisée dans la province ou le territoire). Bien que certains noms n’aient pas de traduction, d’autres en ont. Il est donc la responsabilité de l’émetteur de messages d’assurer une traduction si nécessaire.

Noter que cette exigence n’écarte pas la possibilité d’inclure d’autres codes, comme les codes postaux ou les codes de localisation canadiens d’Environnement Canada (CLC).

Des moyens plus précis d’identification des localisations, comme les polygones du SIG, sont encouragés pour identifier avec plus d’exactitude la région visée par l’alerte. Dans ce contexte, il se peut que les futures exigences d’utilisation d’un géocode dans un message du PC-PAC soient désapprouvées.

Règles du PC-PAC

La présente section énonce les exigences, les contraintes et les recommandations particulières associées au profil canadien de la norme du PAC. Le contenu du PAC est inclus à titre d’information et d’exemple seulement. Les variantes d’interprétation du PAC, le cas échéant, sont involontaires et n’ont pas pour objet de remplacer la norme de référence.

Définitions des éléments du tableau

Élément : élément PAC-XML, tel que décrit dans la norme de référence.
Message :doit renvoyer au contenu du XML en tant que tel, et pas nécessairement à une définition opérationnelle du message énoncé.
Utilisation : règle énonçant les particularités de l’usage d’un élément. Conformément à la norme de référence, il s’agit des utilisations « nécessaires » ou « facultatives », et selon le PC-PAC, des utilisations « nécessaires », « recommandées » ou « facultatives ».
Type : classement de la règle dans la catégorie « technique » (format ou structure) ou « politique » (le domaine de l’alerte au public).
Valeur : valeurs permises pour un élément défini par une règle pour l’élément.
Description : description générale d’une règle et de son objet.
Notes : notes particulières au sujet de la mise en œuvre d’une règle.
Exemple : exemples XML ou articles brefs qui illustrent l’utilisation d’une règle

Schéma <valueName> du PC-PAC

La norme du PAC stipule que les valeurs de « valueName » qui correspondent à un acronyme DEVRAIENT figurer en majuscules sans points. La norme ne formule aucune autre recommandation en ce qui concerne la création d'un <valueName> et la détermination du domaine du code ou de son format. Le <valueName> devrait identifier de façon unique la liste des valeurs utilisée et, lorsque l'on prévoit apporter des changements à la liste de valeurs, il devrait offrir une façon de permettre les modifications en identifiant chaque révision individuelle.

Les spécifications subséquentes du comité d'Oasis qui a établi le PAC sont fondées sur un <valueListUrn> au lieu d'un <valueName>, et on présume que les versions à venir du PAC feront de même. Un nom de ressources uniforme (URN) est un Identificateur de ressources uniformes (URI) décrit dans RFC 1737 de l'Internet Engineering Task Force (EITF). Cependant, pour l'instant, aucun espace de nommage officiel n'est enregistré pour les listes de valeurs du PAC.

Le PC-PAC a adopté un mécanisme de type URN pour créer les valueNames. Même si bon nombre des mêmes principes sont respectés, ce mécanisme est délibérément différent d'un URN pour le distinguer de tout format normalisé futur comprenant un identificateur de nommage officiellement enregistré. Le format suivant sera utilisé pour créer les valueNames du PC-PAC :

<type> ":" <identifier> “:” <specific string>

Le formatage des caractères pour les URN du RFC 2141 sera respecté, incluant l'indifférence des majuscules et minuscules. L'élément <type> sera « profile » ou « layer ». L'élément <identifier> est une chaîne unique qui détermine une liste de valeurs. Il pourrait s'agir de l'organisme qui publie la liste ou le type de liste, et les acronymes devraient suivre les recommandations de la norme du PAC. L'élément <specific string> renferme des renseignements supplémentaires sur cette liste de valeurs, comme un autre nom facilitant l'identification, un sous-segment ou un numéro de version. Par exemple :

profile:CAP-CP:Location:0.3

Les créateurs des couches devraient s'assurer que leurs valueNames respectent ce format, n'entrent pas en conflit avec les valueNames établis du PC-PAC et identifient exclusivement leur organisme.

Veuillez noter que, au moment de la rédaction du présent document, la version actuelle des références (événements, localisations) est 0.3. Vu que les versions de trois documents sont contrôlées indépendamment, les exemples qui suivent reposent sur ces références respectivement.

1. Le message du PC-PAC doit respecter le PAC

PAC

Élément : s.o.

Utilisation :

Type :

Valeur :

Description : La norme de référence

Notes :

Exemple :

PC-PAC

Élément : s.o.

Utilisation : nécessaire

Type : Politique

Valeur :

Description : Tous les messages d’alerte doivent être structurés et formatés conformément aux directives établies par la norme du PAC. Les messages qui ne respectent pas cette norme sont également considérés comme des messages invalides du PC-PAC.

Notes : Les systèmes qui reçoivent des messages invalides du PAC n’auront pas nécessairement à y donner suite; toutefois, au lieu de mettre fin au processus, on recommande d’ajouter un indicateur de type « concern » ou « error » dans le système, et d’informer l’auteur de la raison de l’indicateur. Les destinataires d’un message du PAC pouvant contenir un de ces éléments devraient communiquer avec les responsables du système pour en savoir plus.

Exemple :

(La déclaration suivante concernant l’espace de nommage XML indique que le message du PAC devrait valider le PAC. Dans ce cas-ci, la version 1.2 du PAC est identifiée par l’URN donné. Étant donné que tous les messages du PC-PAC doivent valider le PAC, la ligne suivante demeure une ligne valide dans tous les messages du PC-PAC.)

(Nécessaire)
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
…
</alert>

2. Limite d’un événement par message d’alerte

PAC

Élément : s.o.

Utilisation :

Type :

Valeur :

Description :

Notes : Le PAC n’impose aucune restriction quant au nombre de types d’événements visés par message d’alerte.

Exemple :

PC-PAC

Élément : s.o.

Utilisation : nécessaire

Type : politique

Valeur :

Description : Pour éviter toute confusion potentielle, et conformément aux autres profils du PAC, le PC-PAC limite chaque message d’alerte à un type d’événement.

Notes :

1. La norme du PAC permet l’inclusion d’aucun, d’un ou de plusieurs types d’événement dans un seul message d’alerte, mais d’un seul <identifier> de message unique. Toute mise à jour de l’information relative à un événement donné apparaîtrait comme une mise à jour de l’information concernant tous les autres événements, même si ce n’est pas nécessairement le cas.
2. Une façon pratique de valider cette règle consiste à s’assurer que tous les blocs <info> d’un message d’alerte ont la même valeur <eventCode>.

Exemple :

(Acceptable)

<alert …>
…
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>profile:CAP-CP:Event:0.3</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 1</areaDesc>
<geocode>…</geocode>
</area>
</info>
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
< valueName>profile:CAP-CP:Event:0.3</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 2</areaDesc>
<geocode>…</geocode>
</area>
</info>

(Inacceptable)

<alert …>
…
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
< valueName>profile:CAP-CP:Event:0.3</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 1</areaDesc>
<geocode>…</geocode>
</area>
</info>
<info>
…
<event>Tornado</event>
…
<eventCode>
< valueName>profile:CAP-CP:Event:0.3</valueName>
<value>tornado</value>
</eventCode>
…
<area>
<areaDesc>area 2</areaDesc>
<geocode>…</geocode>
</area>
</info>

3. La version PC-PAC d’un message d’alerte doit être indiquée

PAC

Élément: <code>

Utilisation : facultative

Type : technique

Valeur : Définie par l’utilisateur

Description : Toute valeur définis par l’utilisateur, indicateur ou code spécial pour identifier le message d’alerte pour manipulation spéciale.

Notes :

Exemple :

PC-PAC

Élément : <code>

Utilisation : nécessaire

Type : technique

Valeur : « CAP-CP:0.4 »

Description : Valeur utilisée pour indiquer la ou les versions du PC-PAC auxquelles le message d’alerte vise à se conformer.

Notes : L’élément <code> est un élément à utilisations multiples, et cette utilisation nécessaire pour noter la version n’empêche pas la possibilité d’utiliser le <code> à d’autres fins, comme le référencement des versions, l’identification des couches, les fonctions propres aux systèmes, etc.

Exemple :

(Référence à des versions multiples)
<alert>
…
<scope>public</scope>
<code>profile:CAP-CP:0.4</code>
<code>profile:CAP-CP:1.X</code>
<note></note>
…
</alert>

(Référence à des profils multiples)
</alert>
…
<scope>public</scope>
<code>profile:CAP-CP:0.4</code>
<code>profile:IPAWS :1.0</code>
<note></note>
…

(Référence à une couche supplémentaire)

</alert>
…
<scope>public</scope>
<code>profile:CAP-CP:0.4</code>
<code>layer:EnvironmentCanada:1.0</code>
<note></note>
…

4. Le champ du fuseau horaire doit être inclus dans toutes les variables temporelles
Supprimé du PC-PAC . Le PAC 1.2 aborde maintenant cela dans la norme de référence.

5. Les messages d’alerte pour distribution au public doivent inclure un bloc <info>

PAC

Élément : <msgType>

Utilisation : nécessaire

Type : politique

Valeur : « Alert », « Update », « Cancel », « Ack », « Error »

Description : Valeur indiquant l’état du message d’alerte

Notes :

Exemple:

CAP-CP

Élément : <msgType>

Utilisation : nécessaire

Type : politique

Valeur :

Description :
Les états du message, ainsi que la transition d’un état à l’autre, sont sous-entendus avec l’utilisation des éléments <msgType> et <references>.

1. Pour les messages d’alerte à distribuer au public, l’élément <msgType> des valeurs « Alert », « Update » ou « Cancel » ne change pas l’état du message, et un bloc <info> est nécessaire.
2. Pour les messages d’alerte ayant un <msgType> « Ack » ou « Error », un bloc d’information n’est pas nécessaire, puisque ces messages sont principalement destinés aux fins du système et non pas à la distribution au public.

Notes : Le traitement des fichiers de messages « Ack » ou « Error » est facultatif, et les systèmes peuvent imposer leurs propres règles connexes.

Exemple :

(pour distribution au public)

<alert .. >
…
<status>Actual</status>
<msgType>Alert</msgType>
<source>Environment Canada</source>
<scope>Public</scope>
<code>profile :CAP-CP :0.4</code>
<note />
<references />
<incidents />
<info>
….
</info>
</alert>

(pas pour distribution au public)

<alert .. >
…
<status>Actual</status>
<msgType>Error</msgType>
<source>Environment Canada</source>
<scope>Public</scope>
<code>profile :CAP-CP :0.4</code>
<note>Invalid eventCode</note>
<references>test@ec.gc.ca,TEST-1,2009-01-01T12:00:00-00:00</references>
<incidents />
</alert>

6. Les blocs <Info> doivent préciser la langue du contenu

PAC

Élément : <language>

Utilisation : facultatif

Type : politique

Valeur : définie par RFC 3066

Description : Le code indiquant la langue des sous-éléments du bloc <info> dans le message d’alerte.

Notes : Si la valeur est absente ou nulle, une valeur par défaut implicite de « en-US » DEVRA être présumée.

Exemple :

PC-PAC

Élément : <language>

Utilisation : nécessaire

Type : technique

Valeur :

Description :

1. Tous les messages ayant un bloc <info> doivent inclure l’élément <language> afin d’indiquer la langue du contenu du bloc <info>.
2.  Les messages en plusieurs langues doivent utiliser des blocs <info> distincts pour chaque langue, et tous les éléments textuels à structure imposée doivent être répétés dans chaque bloc.
3. Il n’est pas permis de regrouper le contenu pour affichage public en plusieurs langues dans le même bloc <info>, sauf pour le contenu bilingue en soi (personnes, lieux, choses) pouvant inclure ou non des caractères accentués.

Notes :

1. Les valeurs correspondantes de RFC 3066 pour anglais et français du Canada sont « en-CA » et « fr-CA ». Un message peut être transmis dans d’autres langues parlées au Canada, et les valeurs appropriées devraient être utilisées.
2. UTF-8 est le codage recommandé pour les documents XML afin de soutenir un large éventail de langues et de caractères accentués.
3. Les valeurs fixes du PAC, comme celles qui sont définies pour <urgency>, <severity>, <certainty>, <responseType>, etc. sont en anglais seulement, et sont toujours utilisées comme il est précisé par le PAC au sein de tous les blocs <info>.
4. Le contenu dans le bloc <info>, comme <description>, <ressource> (p. ex., fichiers audio) et liens <web> externes, doit répondre aux besoins de la valeur langue au sein du bloc <info>.

Exemple :

(Les valeurs <event> et <areaDesc> sont traduites dans tous les blocs <info> ci-dessous, parce qu’il s’agit de valeurs pour affichage public. D’autres éléments pour affichage public ne sont pas mentionnés ci-dessous et doivent être traduits, notamment les suivants : <senderName>, <headline>, <description>, <instruction>, <web>, <contact>, <audience> )

<info>
<language>en-CA</language>
<category>Met</category>
<event>Hurricane</event>
<responseType>Monitor</responseType>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
…
<area>
<areaDesc>Avalon Peninsula</areaDesc>
…
</area>
</info>

<info>
<language>fr-CA</language>
<category>Met</category>
<event>Ouragan</event>
<responseType>Monitor</responseType>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
…
<area>
<areaDesc>péninsule d'Avalon</areaDesc>
…
</area>
</info>

7. Utiliser les valeurs <event> établies

PAC

Élément : <event>

Utilisation : nécessaire

Type : technique

Valeur : définie par l’utilisateur

Description : Le texte indiquant l’événement en question du message d’alerte

Notes :

Exemple :

PC-PAC

Élément : <event>

Utilisation : nécessaire

Type : politique

Valeur : Événement tiré du Lexique des événements du PC-PAC

Description : Il est recommandé que la valeur <event> provienne de la liste d’événements du profil lorsqu’il est question d’alertes au public. Ces valeurs prédéfinies et prétraduites assurent l’emploi d’une terminologie uniforme dans les messages d’alerte au public.

Notes :

1. Lors de la création de messages d’alerte au public dans des langues autres que l’anglais ou le français, une traduction de la liste dans la langue appropriée devrait être effectuée à l’avance pour être incluse dans le système.
2. Lors de la création d’alertes au public au moyen du <eventCode> « other », une valeur brève et descriptive <event> devrait être utilisée. On s’attendrait à ce que l’auteur fournisse toutes les traductions nécessaires de ces autres événements. Les noms des événements de niveau I du lexique sont utiles dans cette situation.
3. Le Lexique des événements du PC-PAC n’inclut pas l’article dans le nom de l’événement (c.-à-d. le « d » et l’apostrophe dans le terme… d’orages). La construction automatisée d’expressions formées du mot <event> doit se faire de manière à ce que l’article soit traité séparément.

Exemple :

<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>profile:CAP-CP:Event:0.3</valueName>
<value>thunderstorm</value>
</eventCode>
…
</info>

8. Un <eventCode> reconnu doit être utilisé

PAC

Élément : <eventCode>

Utilisation : facultative

Type : technique

Valeur : définie par l’utilisateur

Description : Code propre au système indiquant le type d’événement du message d’alerte

Notes :

Exemple :

PC-PAC

Élément : <eventCode>

Utilisation : nécessaire

Type : technique

Valeur : La combinaison <valueName> et <value> prise dans le Lexique des événements PC-PAC pour le code associé à un événement.

Description :

1. Le profil exige l’utilisation d’une valeur de code d’événement du Lexique des événements du PC-PAC qui devrait équivaloir à la valeur <event> correspondante.
2. Il y a une limite d’une valeur <eventCode> du Lexique des événements du PC-PAC par message d’alerte, même si des occurrences multiples de l’élément <eventCode> peuvent apparaître dans un message d’alerte.
3. Le format du code d’événement est de 4 à 12 caractères, n’est pas sensible à la casse et ne permet pas les espaces.
4. Le suffixe de version <valueName> change lorsque des nouvelles versions du document Lexique des événements sont publiées. Étant donné que l’élément <eventCode> permet des utilisations multiples, les messages utilisant des codes de différentes versions du Lexique des événements peuvent être, afin d’assurer la rétrocompatibilité et de faciliter la transition entre les mises à jour de la liste.

Notes : Des codes d’événements supplémentaires d’autres listes peuvent être inclus à d’autres fins.

Exemple :

(L’exemple suivant s’appuie sur un <eventCode> de deux lexiques d’événements. L’utilisateur doit déterminer, à partir de l’entrée <valueName>, le lexique qui répond le mieux à ses besoins.)

<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>profile:CAP-CP:Event:0.3</valueName>
<value>thunderstorm</value>
</eventCode>
<eventCode>
<valueName>SAME</valueName>
<value>SVR</value>
</eventCode>

…
</info>

9. Un <geocode> reconnu doit être utilisé

PAC

Élément : <geocode>

Utilisation : facultative

Type : technique

Valeur : définie par l’utilisateur.

Description : Code géographique décrivant la région visée par le message d’alerte.

Notes : L’utilisation de l’élément <geocode> n’est pas encouragée dans le PAC. L’utilisation des éléments <polygon> et <circle> est recommandée et privilégiée.

Exemple :

PC-PAC

Élément : <geocode>

Date de modification :

2022-08-16