Introduction au PC-PAC et ensemble de règles 1.0

>Introduction au PC-PAC et ensemble de règles 1.0 Version PDF (680 KB)

Contrôle des versions

Objet du document

Le présent document décrit un ensemble de règles, des recommandations et une liste gérée de valeurs dont l'utilisation est recommandée dans le Protocole d'alerte commun (PAC) au Canada.

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 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.

La gestion et le contrôle des versions du présent document s'effectuent indépendamment du Lexique des emplacements du PC-PAC et du Lexique des événements du PC-PAC. Par conséquent, il n'est pas nécessaire d'apporter des modifications au présent document chaque fois que les autres sont mis à jour. Cette approche limite la portée des mises à jour à chaque règle, emplacement ou événement, et favorise la concentration spécialisée des participants sur le processus de gestion du changement.

Droits d'auteur

Le présent document est protégé par une licence Creative Commons, qui précise comment il doit être utilisé et communiqué. Plus précisément, le document est diffusé sous la licence Attribution – Partage dans les mêmes conditions 3.0 non transposé de Creative Commons.

À titre d'information, le texte suivant a été traduit à partir de la documentation en ligne de Creative Commons :

Vous être libre de partager (reproduire, distribuer et communiquer) l'œuvre et de remixer (adapter l'œuvre à des fins commerciales) selon les conditions suivantes :

Attribution : Vous devez attribuer l'œuvre de la manière indiquée par l'auteur de l'œuvre ou le titulaire des droits (mais pas d'une manière qui suggérerait qu'ils vous approuvent, vous ou votre utilisation de l'œuvre).

Partage dans les mêmes conditions : Si vous modifiez, transformez ou adaptez cette œuvre, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique ou similaire à celui-ci.

Pour obtenir de plus amples renseignements, consultez le site Web : http://creativecommons.org/licenses/by-sa/3.0/ (en anglais seulement)

Avis

Le présent document et l'information qu'il renferme sont présentés « TELS QUELS »; les auteurs, leurs représentants, leurs employés ou leurs agents DÉSAVOUENT TOUTE GARANTIE OU REPRÉSENTATION, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS NON EXCLUSIVEMENT, TOUTE GARANTIE OU REPRÉSENTATION STIPULANT QUE L'UTILISATION DE L'INFORMATION NE VIOLERA PAS LES DROITS D'AUTRUI ET TOUTE GARANTIE OU REPRÉSENTATION IMPLICITE DE COMMERCIALISATION OU DE PERTINENCE À DES FINS PARTICULIÈRES.

Les versions officielles sont disponibles sur le site Web www.pc-pac.ca.

Acronymes

• Couche s'entend d'un ensemble de renseignements supplémentaires à l'information habituelle, qui est compris dans un message du PAC et dépendant de l'entité d'origine. Un message du PC-PAC peut comporter plusieurs couches.
• CS s'entend du Comité de spécifications du Profil canadien du Protocole d'alerte commun (PC-PAC) 1.0, tel qu'il est établi dans les mandats du PGC pour les SCGUC 1.0.
• CSRGU s'entend des cadres supérieurs responsables de la gestion des urgences. Ces derniers relèvent des sous-ministres fédéraux, provinciaux et territoriaux responsables de la gestion des urgences.
• PGC pour les SCGUC s'entend du processus de gestion du changement établi pour gérer les spécifications sur les communications liées à la gestion des urgences au Canada.
• Profil s'entend d'un ensemble de règles pour l'application de contraintes supplémentaires à l'information habituelle, qui est compris dans un message du PAC et dépendant de l'entité d'origine. Un message du PC-PAC peut avoir plusieurs profils.
• SCGUC s'entend des spécifications sur les communications liées à la gestion des urgences au Canada, qui sont régies par les CSRGU.
• Type d'événement s'entend d'un « événement » réel (c.-à-d. un ouragan) ou présumé (c.-à-d. le terrorisme) sur lequel porte le message d'alerte du PAC.
  

Terminologie

Les termes « DOIT », « NE DOIT PAS », « EXIGÉ », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « FACULTATIF » employés à l'intérieur du présent document doivent être interprétés conformément à la description de la demande des commentaires 2119 de l'IETF, accessible au : http://www.ietf.org/rfc/rfc2119.txt.

Sous-comité du PC-PAC

Le Comité de spécifications peut compter des membres avec et sans droit de vote. Un président et un vice-président doivent être choisis parmi les membres avec droit de vote, et le secrétaire peut avoir ou non un droit de vote.

Représentants avec droit de vote

Les organisations ayant un droit de vote au sujet du présent document sont les suivantes :

• Agence de gestion des urgences de l'Alberta 
• Organisme canadien de gestion d'activités de sécurité publique, anciennement connu sous le nom d'Association canadienne d'avis et d'alerte au public
• Centre des sciences pour la sécurité
• Environnement Canada
• Industrie Canada
• Ressources naturelles Canada
• Pelmorex Communications Inc.
• Sécurité publique Canada
• Ministère de la Sécurité publique du Québec
• NetAlerts Inc.

Représentants sans droit de vote

Les organisations qui supervisent le processus utilisé pour gérer le présent document sont les suivantes :

• Conseil de la radiodiffusion et des télécommunications canadiennes
• Groupe de travail fédéral, provincial et territorial (FPT) sur l'interopérabilité, au nom des cadres supérieurs FPT responsables de la gestion des urgences (CSRGU)
• Sécurité publique Canada – Bureau de développement de l'interopérabilité
• Office des normes générales du Canada (rôle de consultation)

Remerciements

Le Comité de spécifications tient à souligner la participation des personnes suivantes à la préparation du présent Lexique des emplacements du PC-PAC.

• Norm Paulsen (président du Comité)
• Doug Allport
• Khalil Hayek
• Kirsten Wells
• Robert De La Durantaye
• Thomas Poirier-Blanchet
• Philip Dawe
• Wendy Wu
• Tim Trytten
• Jacob Westfall
• Jannick Asselin
• Jeff Conrad
• Noah Moser

Autres documents du PC-PAC

Le PC-PAC comporte trois documents, qui sont disponibles à l'adresse www.PC-PAC.ca. Voici les deux autres documents du PC-PAC :

• Lexique des événements du PC-PAC. Ce document fait état des indicatifs d'événements à utiliser dans le cadre du PC-PAC. Le contrôle des versions est assuré indépendamment du présent document.
• Lexique des emplacements du PC-PAC. Ce document fait état de la terminologie précise des emplacements à utiliser dans le cadre du PC-PAC. Le contrôle des versions est assuré indépendamment du présent document.

De plus, l'annexe suivante peut être consultée :

• Annexe des géocodes du Lexique des emplacements du PC-PAC. Ce document dresse la liste des références des emplacements au Canada à utiliser dans le cadre du PC-PAC. Il est annexé au Lexique des emplacements du PC-PAC et comprend des éléments d'information complémentaires.

Aperçu de l'ensemble de règles du PC-PAC

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

• Contrainte d'un type d'événement par message d'alerte
• Exigences associées à la détermination des événements
• Exigences linguistiques
• Exigences associées à la détermination des emplacements

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.

Contrainte d'un type d'événement par message 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, l'évolution de la situation de n'importe lequel des événements provoquerait l'émission d'un nouveau message du PAC et entraînerait la 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 ces é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 du milieu, les systèmes auraient du mal à traiter un message d'alerte unique qui contiendrait de nombreux événements lorsqu'un seul sous-ensemble d'événements est concerné.

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

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

Pour faire suite à 10.1, 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 les utilisateurs canadiens.  

Étant donné que les alertes canadiennes pourraient être traduites par des applications automatisées, une liste d'événements reconnus prétraduits est fournie. En outre, l'utilisation d'une liste de contrôle <eventcore> facilite la transmission et le filtrage des messages d'alerte selon le type.

Le PC-PAC exige un code d'événement, qui provient d'une liste gérée exhaustive des événements. Cette liste peut être consultée dans le document Lexique des événements du PC-PAC. Comme il a été mentionné, 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. 

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.

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. Dans la version précédente du PC-PAC, des codes de localisation géoréférencés devaient être inclus, comme le définissait le PC-PAC à cet effet. Cependant, comme indiqué dans la version précédente, cette exigence pourrait être considérée comme obsolète dans un avenir plus ou moins rapproché.

L'obsolescence de l'utilisation de codes de localisation géoréférencés dans la présente spécification n'exclut pas leur nécessité dans d'autres spécifications lors d'alertes publiques. Par exemple, l'utilisation de codes de localisation géoréférencés pourrait s'avérer nécessaire pour les entreprises de radiodiffusion qui doivent se soumettre aux normes de l'industrie, reconnue pour utiliser les codes de localisation géoréférencés. Par ailleurs, des systèmes tels le Système interorganisationnel de connaissance de la situation (SICS) sont plus propices à l'utilisation de polygones géospatiaux, sans avoir nécessairement recours à un code de localisation géoréférencé.

Dans cette nouvelle version de la norme du PC-PAC, le terme « lexique des emplacements » a été redéfini pour inclure tous les lexiques des emplacements qui sont conformes au PAC, qu'il s'agisse d'un code de géoréférence ou d'un SIG, c'est-à-dire un polygone ou un élément circulaire. Par conséquent, pour être conforme au PC-PAC, la présence d'un SIG conçu pour PC-PAC ou d'une valeur du lexique des emplacements est nécessaire.

Le PC-PAC continue d'offrir une liste gérée des codes de localisation géoréférencés pour les systèmes qui choisissent de les utiliser. Cette liste peut être consultée dans le document Lexique des emplacements du PC-PAC. Comme il a été mentionné, 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.

Introduction aux règles et recommandations du PC-PAC

Vous trouverez les règles et recommandations du PC-PAC dans les sections suivantes. Pour vous aider à comprendre et à interpréter les tableaux utilisés dans les sections suivantes, nous vous présentons les trois sections explicatives ci-dessous.

Définitions des éléments du tableau

Élément : élément PAC-XML, tel que décrit dans la norme de référence.
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. Dans le PC-PAC, le <valueName> devrait identifier de façon unique la liste de valeurs utilisée et, lorsque des changements sont prévus à la liste de valeurs, il devrait offrir une façon de permettre les modifications en identifiant chaque révision individuelle.

Le PC-PAC a adopté un mécanisme de type URN pour créer les valueNames. 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 de l'IETF 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 cette 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:1.0

Les créateurs de 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 les trois versions des documents du PC-PAC sont contrôlées indépendamment et que les versions utilisées dans les exemples qui suivent le sont à titre de référence uniquement.

Tableau reliant les éléments du PAC au PC-PAC

Le tableau suivant identifie chaque élément du PAC et toute règle ou recommandation du PC-PAC qui y fait référence :

Ensemble de règles du PC-PAC

La présente section énonce les exigences et les contraintes particulières associées à l'ensemble de règles du PC-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.

Règle no 1. Le message du PC-PAC doit respecter le PAC

Élément : s.o.

Utilisation :

Type :

Valeur :

Description : La norme de référence

Notes :

Exemple :

É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 :

Règle no 2. Contrainte d'un événement par message d'alerte

É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 :

É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 événement.

Notes :

• 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.
• 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 :

(1) (Acceptable)

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

(2) (Non acceptable)

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

Règle no 3. La version PC-PAC d'un message d'alerte doit être indiquée

Élément : <code>

Utilisation : facultative

Type : technique

Valeur : Définie par l'utilisateur

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

Notes :

Exemple :

Élément : <code>

Utilisation : nécessaire

Type : technique

Valeur : profile:CAP-CP:1.0

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

Notes :

1. La valeur <code> est un élément à usage multiple. 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 d'un autre profil, l'identification des couches ou les fonctions propres aux systèmes.

Exemple :

(Référence à des profils multiples)
<alert>
.
<scope>Public</scope>
<code>profile:CAP-CP:1.0</code>
<code>IPAWS v1.0</code>
<note></note>
.

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

<alert>
.
<scope>Public</scope>
<code>profile:CAP-CP:1.0</code>
<code>layer:EnvironmentCanada:1.0</code>
<note></note>
.

Règle no 4. Les messages d'alerte pour distribution au public doivent inclure un bloc <info>

Élément : <msgType>

Utilisation : nécessaire

Type : Politique

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

Description : Valeur indiquant l'état de l'alerte au moment de diffuser le message.

Notes :

Exemple :

Élément : <msgType>

Utilisation : nécessaire

Type : Politique

Valeur :

Description :
Les états d'alerte, 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 » change le message à communiquer au public visé; par conséquent, 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 fichiers 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:1.0</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:1.0</code>
<note >Invalid eventCode</note>
<references >test@ec.gc.ca,TEST-1,2009-01-01T12:00:00-00:00</references>
<incidents />
</alert>

Règle no 5. Les blocs <Info> doivent préciser la langue du contenu

Élément : <language>

Utilisation : facultative

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 :

É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 prendre en charge 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>.

Le contenu dans le bloc <info>, comme <description>, <resource> (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>

Règle no 6. Un <eventCode> reconnu doit être utilisé

É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 :

Élément : <eventCode>

Utilisation : nécessaire

Type : technique

Valeur : la paire <valueName>,<value> pour le code d'événement associé à un événement du Lexique des événements du PC-PAC.

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 de la Liste d'é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 indiquer, à partir de l'entrée <valueName>, la liste qui répond à ses besoins.)

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

  .
</info>

Règle no 7. Le Lexique des emplacements est requis

Élément : <geocode> <polygon> <circle>

Utilisation : facultative

Type : technique

Valeur : Définie par l'utilisateur

Description : Une référence géographique à un emplacement ou plus, où l'information figurant dans le message PAC est pertinente.

Notes : Dans PAC, l'utilisation des éléments <polygon> et <circle> est recommandée et privilégiée.

Exemple :

Élément : <geocode> <polygon> <circle>

Utilisation : nécessaire

Type : technique

Valeur : Au moins un des éléments <geocode> <polygon> ou <circle> doit détenir une valeur valide, puisque si l'on utilise uniquement <geocode>, il doit avoir une valeur qui est conforme à l'ensemble des géocodes du Lexique des emplacements du PC-PAC.

Description :

1. Le profil nécessite l'utilisation d'au moins une valeur <geocode> du Lexique des emplacements du PC-PAC, soit <polygon> ou <circle>.
2. D'autres valeurs <geocode> provenant d'autres systèmes de codes peuvent être utilisées en option avec ce qui précède.
3. Lors de l'utilisation d'éléments de localisation, autant d'éléments que nécessaire pour couvrir la totalité de la région visée du message d'alerte peuvent être utilisés. REMARQUE : Lors de l'utilisation d'éléments <geocode>, il est recommandé, lorsque possible, d'utiliser un élément <geocode> plus élevé, comme défini dans le Lexique des emplacements du PC-PAC, afin de remplacer plusieurs éléments <geocode> inférieurs.
4. Pour l'utilisation d'éléments <geocode>, le <valueName> respectif conformément à la version du Lexique des emplacements du PC-PAC duquel le <geocode> a été tiré doit être compris.

Notes :

1. Des codes de localisation supplémentaires provenant d'autres listes comme un CLC ou un code postal peuvent être ajoutés à un message PC-PAC, mais sont considérés comme extérieurs à la norme PC-PAC. On ne s'attend pas à ce qu'ils soient utilisés à l'exception des parties qui s'y identifient (remarque : le CLC est un code de localisation de Radiométéo Canada).
2. Plusieurs éléments <geocode> provenant de différentes versions du Lexique des emplacements du PC-PAC peuvent être intégrés à un message du PC-PAC.
3. L'utilisation de la valeur d'un élément <geocode> provenant d'une version antérieure ou postérieure du Lexique des emplacements du PC-PAC plutôt que le présent ensemble de règles du PC-PAC est permise (p. ex. un système peut adopter les règles du PC-PAC v1.0 et toujours utiliser le Lexique des emplacements du PC-PAC Bêta 0.4.)

Exemple :

(Dans le premier exemple, le premier <geocode> renvoie à une division de région, tandis que le deuxième <geocode> renvoie à une subdivision de région, toujours dans le même bloc <info>. Le lexique des emplacements pour le message est l'union des deux emplacements référencés.)

<info>
…
<area>
…
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>3506</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>3507004</value>
</geocode>
…
</area>
…
</info>

(Le deuxième exemple renvoie à un <geocode> provenant de deux listes de références de localisations. Le destinataire doit indiquer, à partir de l'entrée, le lexique qui répond à ces besoins.)

<info>
…
<area>
…
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>3506</value>
</geocode>
<geocode>
<valueName>PostalCode:2011</valueName>
<value>M4R2S8</value>
</geocode>
…
</area>
…
</info>

(Dans le troisième exemple, le premier <geocode> renvoie à la valeur d'une précédente liste du Lexique des emplacements du PC-PAC, tandis que le deuxième <geocode> renvoie à la valeur d'une liste ultérieure du Lexique des emplacements du PC-PAC)

La localisation référencée dans les deux listes provenant de versions différentes est essentiellement la même localisation, mais une modification de la définition de localisation a été apportée entre ces versions. La version plus récente reflète davantage le lexique de l'emplacement cible. La version précédente permet aux systèmes configurés antérieurement de demeurer fonctionnels.

<info>
…
<area>
…
<geocode>
<valueName>profile:CAP-CP:Location:0.4</valueName>
<value>2429065 /value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>29073 </value>
</geocode>
…
</area>
…
</info>

Le Lexique des emplacements du PC-PAC 2429065 dans la version 0.4 (partie de Saint-Philibert) devient le Lexique des emplacements 2429073 dans la version 1.0 (partie de Saint-Georges) à la suite de la mise à jour de l'enregistrement foncier au Québec et des changements des limites territoriales de plusieurs municipalités.

(Dans le quatrième exemple, un seul <polygon> est utilisé)

<info>
…
<area>
…
<polygon>47.6325,-70.5033 47.4732,-70.2871 47.4425,-70.2483 47.3334,-70.3551 47.1601,-70.5438 47.0116,-70.7199 47.0684,-70.7868 47.1831,-71.016 47.1833,-71.0163 47.1835,-71.016 47.6324,-70.5035 47.6325,-70.5033</polygon> 
…
</area>
…
</info>

Règle no 8. Les blocs <area> sont nécessaires

Élément : <area>

Utilisation : facultative

Type : technique

Valeur :

Description : renferme le sous-élément de la région

Notes :

Exemple :

Élément : <area>

Utilisation : nécessaire

Type : technique

Valeur :

Description :
1 Un bloc <area> est nécessaire pour chaque bloc <info>.
2 L'élément <areaDesc> décrit la région combinée des emplacements énumérés et, comme l'élément <event>, il ne s'agit pas nécessairement d'un nom qui se trouve dans le Lexique des emplacements.

Notes :
Les descriptions des régions (comme les événements) devront être traduites par l'auteur du message pour les messages contenant les blocs <info> en anglais et en français, dans les cas où les noms des emplacements ne figurent pas dans le Lexique des emplacements.

Exemple :

<info>
…
<area>
<areaDesc>Shawinigan Area</areaDesc>
<polygon>-73.2174,46.7498 -72.5497,46.7665 -72.5497,46.7665
-72.4830,46.6498 -72.4830,46.6498 -72.4330,46.5832 -72.433,46.5832
-72.8832,46.3998 -72.8832,46.3998 -72.8833,46.4000 -72.8833,46.4000
-72.9666,46.5333 -73.1389,46.5201 -73.1389,46.5201 -73.1858,46.5139
-73.1858,46.5139 -73.2174,46.7498 </polygon>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>2435040</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>2435027</value>
</geocode>
…
</area>
</info>

Règle no 9. Un message de mise à jour ou d'annulation devrait au moins inclure des renvois à tous les messages actifs

Élément : <references>

Utilisation : facultative

Type : technique

Valeur :

Description : élément qui énumère les messages précédents dont il est question dans le message d'alerte.

Notes : La copie normative de la norme du PAC nécessite l'élément <references> pour les valeurs « Update » et « Cancel », mais elle n'est pas mise en pratique dans le schéma.

Exemple :

Élément : <references>

Utilisation : nécessaire

Type : politique

Valeur :

Description :

1. Conformément à la copie normative de la norme du PAC, l'élément <references> est nécessaire avec les valeurs <msgType> du CAP pour « Update » ou « Cancel ».
2. De plus, le PC-PAC nécessite des renvois à tous les messages actifs (ceux qui ont au moins un bloc <info> actif) dont l'état est touché par le nouveau message. Un bloc <info> « active » n'a pas encore atteint une expiration <expires>.
3. Dans le cas d'un bloc <info> qui n'a pas d'expiration <expires>, tous les messages subséquents de la chaîne devraient inclure un renvoi à ce message, qui n'a pas d'expiration en soi.

Notes : Le référencement de tous les messages d'alerte avec un bloc <info> qui ont encore une expiration <expires> ultérieure veille à ce que tous les messages qui sont encore erronés soient tout de même remplacés par la mise à jour ou l'annulation la plus récente. Cette procédure règle les problèmes causés par les délais de transmission ou les messages perdus pouvant entraîner la rupture des chaînes de messages. Si une seule référence était utilisée, un message manqué pourrait entraîner le maintien d'une alerte au-delà de sa durée prévue.

Exemple :

(Le premier message d'alerte ayant un délai d'expiration de trois heures)

<alert … >
<identifier>ABC-7</identifier>
<sender>A@ca</sender>
<sent>2008-01-01T01:00:00-00:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
…
<references></references>
<info>
…
<expires>2008-01-01T04:00:00-00:00</expires>
…
</info>
…
</alert>

(Mise à jour subséquente ayant un délai d'expiration de trois heures, avec renvoi au premier message)

<alert … >
<identifier>ABC-8</identifier>
<sender>A@ca</sender>
<sent>2008-01-01T02:00:00-00:00</sent>
<status>Actual</status>
<msgType>Update</msgType>
…
<references>A@ca,ABC-7,2008-01-01T01:00:00-00:00</references>
<info>
…
<expires>2008-01-01T05:00:00-00:00</expires>
…
</info>
…
</alert>

(Autre mise à jour subséquente ayant un délai d'expiration de trois heures, avec renvoi aux deux premiers messages)

<alert … >
<identifier>ABC-9</identifier>
<sender>A@ca</sender>
<sent>2008-01-01T03:00:00-00:00</sent>
<status>Actual</status>
<msgType>Update</msgType>
…
<references>A@ca,ABC-7,2008-01-01T01:00:00-00:00 A@ca,ABC-8,2008-01-01T02:00:00-00:00</references>
<info>
…
<expires>2008-01-01T06:00:00-00:00</expires>
…
</info>
…
</alert>

(Autre mise à jour subséquente ayant un délai d'expiration de trois heures, avec renvoi aux deux derniers messages, puisque le premier est expiré et devrait être désactivé pour deux raisons : 1) il a été remplacé, ou 2) il est expiré)

<alert … >
<identifier>ABC-10</identifier>
<sender>A@ca</sender>
<sent>2008-01-01T04:00:00-00:00</sent>
<status>Actual</status>
<msgType>Update</msgType>
…
<references>A@ca,ABC-8,2008-01-01T02:00:00-00:00 A@ca,ABC-9,2008-01-01T03:00:00-00:00</references>
<info>
…
<expires>2008-01-01T07:00:00-00:00</expires>
…
</info>
…
</alert>

Règle no 10. Utiliser les valeurs <event> établies

É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 :

É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 aussi de la liste d'événements du PC-PAC. Ces valeurs prédéfinies et prétraduites aident à garantir l'emploi d'une terminologie uniforme pour décrire les événements dans les messages d'alerte au public.

Notes :

1. Les autorités qui utilisent les valeurs <event> autres que celles qui figurent dans la liste d'événements du PC-PAC, devront les mapper au code d'événements du Lexique des événements afin de se conformer au PC-PAC. Les noms <event> du PC-PAC peuvent donc être dérivés en utilisant la valeur du code d'événements.
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 des événements sont utiles dans cette situation.
3. 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.
4. La liste des événements du PC-PAC ne comprend pas les articles dans le nom de l'événement (c.-à-d. le « d » et l'apostrophe dans le terme… d'orages). Toutefois, les articles contenus dans le nom sont inclus puisqu'ils sont toujours présents et apparaissent dans l'affichage de <event>. 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:1.0</valueName>
<value>thunderstorm</value>
</eventCode>
…
</info>

Règle no 11. Indiquer lorsqu'un message de mise à jour comporte des modifications de contenu non essentielles

Élément : <parameter>

Utilisation :

Type :

Valeur :

Description : Paramètre supplémentaire propre au système associé au message d'alerte.

Notes : La valeur « Update » de <msgType> met à jour et remplace les messages antérieurs indiqués dans <references>. Par conséquent, le message à jour doit refléter l'état complet de l'événement, et il s'agit toujours par défaut d'une modification importante.

Exemple :

Élément : <parameter>

Utilisation : recommandée

Type : politique

Valeur : Une <valueName> de « profile:CAP-CP:1.0:MinorChange » et une <value> de « none », « text », « correction », « resource », « layer » ou « other ».

Description : Ce paramètre a pour objet de permettre la prise de décisions importantes concernant la distribution en vue de réduire le nombre de cas de surabondance d'alertes.

1. Ce paramètre peut seulement être utilisé lorsque l'élément <msgType> est « Update » et que l'élément <references> est correctement rempli.
2. Ce paramètre peut seulement être utilisé lorsque tous les blocs <info> d'un message contiennent des modifications non essentielles du contenu ou aucune modification. L'ajout ou la suppression d'un bloc <info> par rapport au message antérieur constitue un changement important.
3. L'ajout, la suppression ou la modification des éléments suivants peuvent être considérés comme non essentiels : les blocs <audience>, <headline>, <description>, <instruction>, <web>, <contact>, <parameter>, <areaDesc> et <resource>. Les systèmes expéditeurs et destinataires sont libres d'imposer des contraintes supplémentaires sur ce qu'ils considèrent comme des modifications non essentielles.
4. Lorsqu'un message d'alerte est considéré comme une mise à jour mineure, tous les blocs <info> doivent contenir une ou plusieurs valeurs de paramètre « MinorChange », et la valeur fixée doit refléter la modification mineure. 
5. Un élément <note> peut être utilisé pour expliquer plus en détail la raison des modifications mineures dans cette mise à jour.
6. Lorsqu'aucune modification n'est survenue dans un bloc <info> par rapport au message précédent, la valeur « none » devrait être utilisée.
7. Lorsqu'une modification est survenue entre blocs <info>, où du contenu textuel libre peut avoir été ajouté ou modifié, la valeur « text » devrait être utilisée dans les blocs <info> lorsqu'il y a lieu.
8. Lorsqu'une correction est apportée à une partie du contenu libre, peut-être à cause d'une erreur, d'une faute d'orthographe ou d'une omission, la valeur « correction » devrait être utilisée dans les blocs <info> lorsqu'il y a lieu.
9. Lorsqu'un bloc <resource> et son contenu connexe sont ajoutés, modifiés ou supprimés par rapport au message précédent, la valeur « resource » devrait être utilisée dans les blocs <info> lorsqu'il y a lieu.
10. Lorsque des valeurs en couches sont ajoutées, modifiées ou supprimées par rapport au message précédent, la valeur « layer » devrait être utilisée dans les blocs <info> lorsqu'il y a lieu.
11. Lorsque la modification du contenu ne répond pas aux critères des autres valeurs du paramètre, la valeur « other » devrait être utilisée dans les blocs <info> lorsqu'il y a lieu. Un élément <note> devrait toujours être utilisé avec les modifications « other ».
12. Les valeurs « none », « text », « correction », « resource », « layer » et « other » ne font pas la distinction entre les minuscules et les majuscules et ne doivent pas être traduites.

Notes :

1. La décision de traiter du contenu non essentiel et de le présenter incombe à l'expéditeur ou au destinataire.
2. Lorsqu'un destinataire décide d'ignorer ce paramètre et cette valeur, tous les messages de mise à jour devraient être considérés comme essentiels, conformément à l'objet de la norme du PAC.
3. Lorsqu'une erreur de transmission survient et que le destinataire ne reçoit pas le message précédent en référence auquel s'applique la modification non essentielle, le message actuel devrait être considéré comme essentiel.

Exemple :

(Mise à jour initiale)

<alert … >
<identifier>CA-EC-CWTO-2008-13</identifier>
…
<references>cwto@ec.gc.ca,CA-EC-CWTO-2008-11,2008-07-16T16:00:00-00:00</references>
…
<info>
…
<language>en-CA</language>
…
<area>
<areaDesc>Sainte-Anne-de-la-Perade</areaDesc>
</area>      
</info>
</alert>

(Mise à jour mineure subséquente)

(Le message suivant visait à corriger l'épellation du nom. Dans ce cas, comme il n'y avait pas d'accent sur le segment Pérade au départ, une mise à jour mineure a été apportée. Étant donné qu'aucun autre élément du message PAC en question n'a été modifié, le message aurait pu être laissé tel quel sans devenir incorrect, sauf pour l'épellation du nom de lieu. Certains distributeurs pourraient décider de ne pas renvoyer l'alerte en fonction de cette modification, préférant limiter la surabondance d'alertes, tandis que d'autres ayant des systèmes d'affichage passifs donneraient probablement suite à cette mise à jour.)

<alert … >
<identifier>CA-EC-CWTO-2008-14</identifier>
…
<references>cwto@ec.gc.ca,CA-EC-CWTO-2008-11,2008-07-16T16:00:00-00:00 cwto@ec.gc.ca,CA-EC-CWTO-2008-13,2008-07-16T16:00:00-00:00</references>
…
<info>
…
<language>en-CA</language>
…
<parameter>
<valueName>profile:CAP-CP:1.0:MinorChange</valueName>
<value>correction</value>
</parameter>
…
<area>
<areaDesc>Sainte-Anne-de-la-Pérade</areaDesc>
</area>      
</info>
</alert>

Recommandations du PC-PAC

La présente section énonce 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.

Recommandation 1. Traitement préférentiel de <polygon> et <circle>

Élément : <area>

Utilisation : facultative

Type : technique

Valeur :

Description :
(1) Les multiples occurrences sont permises, auquel cas la région cible du bloc <info> est l'union de tous les blocs <area> inclus.
(2) PEUT contenir une ou plusieurs occurrences de <polygon>, <circle> ou <geocode>. Si les éléments multiples <polygon>, <circle> ou <geocode> sont inclus, le lieu décrit par cet élément <area> est l'union de ceux représentés par les éléments inclus.

Notes : Les valeurs <geocode> sont corrélées à des lieux géospatiaux prédéfinis, comme c'est le cas pour les codes de la Classification géographique type (CGT), puisqu'ils servent de base au Lexique des emplacements terrestres du PC-PAC.

Exemple :

Élément :

Utilisation : facultative

Type : technique

Valeur :

Description :

Le PC-PAC exige une valeur <geocode> PC-PAC ou l'utilisation des valeurs optionnelles <polygon> et <circle>. Lorsque les valeurs <polygon> ou <circle> sont présentes dans un bloc région, la combinaison de ces valeurs <polygon> et <circle> est la représentation la plus exacte de la région d'alerte que la combinaison des valeurs <polygon>, <circle> et <geocode> soutenue par le PAC. Cette distinction permet aux auteurs du PAC de soutenir les systèmes d'alerte qui nécessitent des géocodes et de pouvoir représenter de façon plus précise la région ciblée à l'aide des constructions SIG dans un message PAC. Par exemple, l'utilisation d'un code de localisation pour une ville entière à l'aide d'un polygone représentant une alerte particulière à quelques blocs seulement.

Notes : La (les) région(s) associée(s) avec le <geocode> est(sont) souvent beaucoup plus vaste(s) que la région d'alerte ciblée, ce qui donne lieu à une suralerte. Les destinataires qui entendent traiter un message du PC-PAC peuvent choisir d'identifier la région d'alerte par les éléments <polygon> et <circle> seulement, sachant que cela ne représente rien de plus que la pleine région d'alerte visée.

Exemple :

<info>
…
<area>
<areaDesc>Shawinigan Area</areaDesc>
<polygon>-73.2174,46.7498 -72.5497,46.7665 -72.5497,46.7665
-72.4830,46.6498 -72.4830,46.6498 -72.4330,46.5832 -72.433,46.5832
-72.8832,46.3998 -72.8832,46.3998 -72.8833,46.4000 -72.8833,46.4000
-72.9666,46.5333 -73.1389,46.5201 -73.1389,46.5201 -73.1858,46.5139
-73.1858,46.5139 -73.2174,46.7498</polygon>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>2435040</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>2435027</value>
</geocode>
…
</area>
</info>

Le <polygon> fourni est une représentation plus exacte de la région d'alerte que la combinaison des fichiers frontaliers associés aux valeurs <geocode> incluses dans l'alerte.

Recommandation 2. L'élément <sender> devrait être descriptif

Élément : <sender>

Utilisation : nécessaire

Type : technique

Valeur : définie par l'utilisateur

Description : Identifie l'auteur du message d'alerte

Notes :

Exemple :

Élément : <sender>

Utilisation : nécessaire

Type : politique

Valeur :

Description :

1. Doit pouvoir être lu par l'humain.
2. Doit indiquer l'organisme qui a compilé le message, qui aurait pu être fait pour le compte d'un autre organisme à l'origine du message. Par exemple, lorsqu'une municipalité rédige une alerte qui est publiée par un organisme provincial, <sender> est l'organisme provincial et <senderName> est la municipalité.
3. L'élément doit être le plus unique possible. Par exemple, un nom de domaine Internet intégré à <sender> est une façon de créer un nom unique.

Notes : Lorsqu'un message d'alerte créé par un autre organisme est traité dans un système, comme un agrégateur, sans modification, alors l'élément <sender> peut demeurer tel quel. Toutefois, si des modifications sont apportées au message, ou si l'agrégateur représente l'autorité pour ses clients, la valeur <sender> devrait être modifiée pour refléter l'agrégateur.

Exemple :

Le bureau de Montréal d'une autorité compétente a reçu de l'information d'alerte d'un autre bureau dans un format hors PAC et a par la suite reformaté les données en format PAC et redistribué le message. Dans ce cas, « Montréal » est un élément lisible par l'humain et « @[domain] » assure le caractère unique.
…
<sender> Montreal@gc.ca</sender>
…

Remarque : L'exemple n'est pas une vraie valeur.

Vous trouverez ci-dessous un exemple à deux volets d'un nom lisible par l'humain ayant un caractère unique. Il s'agit du « centre des opérations » de l'« Organisation des mesures d'urgence du Nouveau-Brunswick » qui fait partie du « gouvernement du Nouveau-Brunswick ».
…
<sender>operations-center@EMO@gnb.ca</sender>
…

Remarque : L'exemple n'est pas une vraie valeur.

Recommandation 3. Il est fortement recommandé d'utiliser un <senderName>

Élément : <senderName>

Utilisation : facultative

Type : technique

Valeur :

Description : Le nom lisible par l'humain de l'organisme ou de l'autorité émettant le bloc <info> du message d'alerte.

Notes :

Exemple :

Élément : <senderName>

Utilisation : recommandée

Type : politique

Valeur :

Description : Il est fortement recommandé que cet élément soit rempli par les auteurs des messages, puisque cette valeur est censée être utilisée à des fins de présentation au public.

Notes : La valeur adéquatement traduite pour le nom devrait être utilisée dans chaque bloc <info> d'un message d'alerte en plusieurs langues.

Exemple :

<info>
…
<language>en-CA</language>
<senderName>Environment Canada</senderName>

</info>
<info>

<language>fr-CA</language>
<senderName>Environment Canada</senderName>

</info>

Recommandation 4. L'élément <responseType> est fortement recommandé, s'il y a lieu

Élément : <responseType>

Utilisation : facultative

Type : politique

Valeur :

Description : Code indiquant le type de mesure recommandé pour le public cible.

Notes : Plusieurs instances PEUVENT survenir dans un seul bloc <info>.

Exemple :

Élément : <responseType>

Utilisation : recommandée

Type : politique

Valeur :

Description : Il est recommandé que les expéditeurs du message d'alerte incluent les types de réponses lorsqu'il y a lieu, ainsi qu'une valeur <instruction> correspondante. L'utilisation de l'élément <responseType> permet la diffusion automatisée dans toutes les langues incluses des mesures que l'utilisateur final devra prendre lorsque les instructions ne sont pas nécessairement disponibles, ou qu'elles ne sont pas disponibles dans toutes les langues.

Notes :

Exemple :

<info>
…
<responseType>Shelter</responseType>
<responseType>Monitor</responseType>
<instruction>Take cover as threatening conditions approach and monitor local media broadcasts for further updates</instruction>
…
</info>

Recommandation 5. Indiquer la traduction automatisée du texte libre

Élément : <parameter>

Utilisation :

Type :

Valeur :

Description : Paramètre supplémentaire propre au système associé au message d'alerte.

Notes :

Exemple :

Élément : <parameter>

Utilisation : facultative

Type : politique

Valeur : L'élément <valueName> du « profile:CAP-CP:1.0:AutoTranslated » et un élément <value> qui est « yes » ou « no ».

Description : On appelle traduction automatique tout type de traduction machine de texte libre, ou l'organisation d'expressions suivant des valeurs préétablies, où l'on n'a pas fait appel à un traducteur en chair et en os. Cette règle a pour objet de faciliter la prise d'importantes décisions concernant la distribution des messages en plusieurs langues.

1. Lorsqu'une traduction automatique de texte libre dans un bloc <info> a été effectuée, une seule instance de ce paramètre devrait être utilisée avec la valeur « yes ».
2. Pour les messages d'alerte ayant plusieurs blocs <info>, seuls les blocs <info> visés par cette traduction automatique devraient utiliser le paramètre.
3. Lorsqu'un message de mise à jour est émis pour un bloc <info> qui contient du texte libre ayant fait l'objet d'une révision subséquente par une personne, qui a corrigé la traduction et remplacé le contenu traduit automatiquement, ce paramètre devrait être utilisé avec la valeur « no ».
4. Les valeurs « yes » et « no » ne sont pas sensibles à la casse et ne doivent pas être traduites. 

Notes :

1. La décision de traiter et la présentation subséquente du contenu traduit par ordinateur sont la responsabilité du destinataire.
2. Les considérations relatives à la traduction et aux exigences multilinguistiques sont nombreuses et doivent être abordées dans les documents justificatifs.
3. Les émetteurs qui entendent utiliser la traduction automatisée doivent fournir la documentation justificative indiquant quels éléments sont autotraduits ou ont été autotraduits.

Exemple :

(Dans l'alerte qui suit, la description a été générée en anglais par un logiciel interprétant un type de réaction au lieu d'une phrase libre entrée par une personne en français. Dans les cas où le texte de la langue de départ n'est pas aussi simple que dans l'exemple, les interprétations peuvent être problématiques. Par conséquent, il suffit d'utiliser un élément de paramètre simple pour indiquer l'activité de traduction automatique de l'auteur.)

<alert … >
…
<info>
<language>en-CA</language>
…
<instruction>Take shelter as threatening or hazardous conditions arrive.
</instruction>
<parameter>
<valueName>profile:CAP-CP:1.0:AutoTranslated</valueName>
<value>Yes</value>
</parameter>
…
</info>
<info>
<language>fr-CA</language>
…
<responseType>Shelter</responseType>
<instruction>En menaçant des approches de temps, prenez l'abri à l'intérieur et surveillez la radio locale pour d'autres mises à jour
</instruction>
…
</info>
</alert>

Dans l'alerte ci-dessus, il est évident que le paramètre de traduction automatique fait référence à l'élément instruction. Toutefois, dans bien des cas, ce n'est pas aussi évident et, avec plusieurs éléments du PAC pouvant contenir du texte et un paramètre pour les modifier, il faudra une explication détaillée dans les documents d'appui pour que ce paramètre soit utile aux distributeurs finaux.

Date de modification :

2022-08-16