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

Norme de référence : OASIS – Emergency Data Exchange Language – Common Alerting Protocol (EDXL-CAP) version 1.2.

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.
• Jeff Boyczuk, Sécurité publique Canada
• April Diver, Alberta Emergency Management Agency
• Khalil Hayek, Ressources naturelles Canada
• Norm Paulsen, Environnement Canada
• Jacob Westfall, Net Alerts
• Wendy Wu, Industrie Canada

Droits d’auteur

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

De plus, le contenu de ce document peut être utilisé pour créer d’autres documents, à condition que la contribution du PC-PAC soit reconnue et qu’on indique clairement dans le nouveau document qu’il ne s’agit pas d’un document officiel du PC-PACé

Avis

Le présent document et l’information qu’il contient sont présentés sur une base « TELLE QUELLE », et les auteurs, leurs officiers, employés ou agents DÉSAVOUENT TOUTE GARANTIE OU REPRÉSENTATION, EXPRESSE OU IMPLICITE, COMPRENANT, SANS S’Y LIMITER, TOUTE GARANTIE OU REPRÉSENTATION QUE L’UTILISATION DE CETTE INFORMATION N’EMPIÉTERA PAS SUR LES DROITS DES AUTRES, OU TOUTE GARANTIE OU REPRÉSENTATION IMPLICITE DE COMMERCIALISATION OU D’UTILITÉ POUR UN BUT PRÉCIS.

Sommaire des révisions

Le présent document ne comprend pas de révision majeure apportée à la version Bêta 0.4. Les révisions apportées sont :

1. Changement à l’énoncé des droits d’auteur
2. Ajout d’une référence vers le site www.PC-PAC.ca
3. Ajout de commentaires sur la règle no 1 sur le respect du PAC
4. Amélioration de la formulation de la règle no 3 sur la version PC-PAC
5. Commentaires liés à la règle no 4sur le fuseau horaire
6. Amélioration de la formulation de la règle no 5 sur le bloc <info>
7. Commentaires liés à la règle no 13 sur la valeur <expires>
8. Commentaires liés à la règle no 17 sur la traduction automatique

Autres documents relatifs au PC-PAC

Le PC-PAC est entièrement défini dans le présent document et les deux documents indiqués ci-dessous, qui se trouvent tous sur le site www.PC-PAC.ca.

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.

Consultez le www.PC-PAC.ca pour voir les mises à jour au document.

Documents et ressources connexes

1. La norme de référence, le Emergency Data Exchange Language Common Alerting Protocol (EDXL-CAP ou CAP) version 1.2, est une norme administrée par OASIS (Organization for the Advancement of Structured Information Standards). Les versions actuelle et précédentes de la norme sont disponibles sur le site Web suivant : http://docs.oasis-open.org/emergency/cap/.
2. Le site Web du PC-PAC (www.PC-PAC.ca) présente des ressources et des liens liés au PC-PAC.

Il est à noter que la version 0.4 du PC-PAC a été lancée pour s’harmoniser à la version 1.2 du PAC. Il a fallu modifier le PC-PAC, car la règle no 4 a été retirée de la version 0.3 du PC-PAC. Si le lancement de la version 1.2 du PAC n’avait pas entraîné de changement important, un avis aurait été publié pour qu’on se réfère à la nouvelle version du PAC en tant que norme de référence.

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, disponible 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,

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, étant donné que la liste est susceptible de changer pour tenir compte des besoins 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 l’ensemble des utilisateurs qui s’identifient au profil. Un profil fournit le contexte nécessaire pour l’activité d’alerte au sein d’un pays ou d’un 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.

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 inc. 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 des gouvernements fédéral et provinciaux 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).

Gestion du PC-PAC

Le PC-PAC est géré par un petit groupe d’intervenants connu sous le nom de Groupe de travail sur le PC-PAC. Le site Web du Groupe de travail est hébergé sur celui de l’ACAAP.

En 2010, l’ACAAP a obtenu un financement pour appuyer un modèle de gouvernance et une étude sur la gestion du changement appuyée par tous les membres du Groupe de travail sur le PC-PAC. Les membres de l’équipe chargée du projet ont conclu que le PC‑PAC avait besoin d’une gouvernance nationale et d’un processus officiel de gestion du changement comprenant une période d’examen public. Ils ont également réaffirmé que le PC-PAC serait géré en version bêta jusqu’à ce que le modèle de gouvernance et le processus de changement appropriés soient en place.

En janvier 2011, la Stratégie d’interopérabilité des communications pour le Canada est venue définir une structure de gouvernance nationale comprenant un rôle de coordination pour le nouveau Bureau de développement de l’interopérabilité (BDI) de Sécurité publique Canada (SP). Le Plan d’action d’interopérabilité des communications pour le Canada connexe présente le PC-PAC comme une priorité nationale et énonce les priorités associées à sa gestion.

En 2012, le BDI de SP terminera un processus officiel de gestion du changement relatif aux caractéristiques des communications d’urgence qui sera supervisé par les Cadres supérieurs responsables de la gestion des urgences (CSRGU). La version 1.0 du PC-PAC suivra ce processus dans le cadre de sa nouvelle structure de gouvernance.

Au sujet des couches

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

Les couches sont simplement une façon structurée de permettre l’extension du PAC et du PC-PAC. Les extensions sont fondamentales à la conception des documents XML, et l’utilisation structurée de l’élément <parameter> officialise l’application de ce principe de base dans l’ensemble du milieu. L’intégrité de la norme de référence et du profil canadien est maintenue, tout en permettant l’utilisation et la gestion du PC-PAC sans limiter son potentiel de service à une utilisation, un utilisateur ou un système unique.

Aperçu du PC-PAC

Le PC-PAC est surtout axé sur quatre exigences et contraintes principales, 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 du milieu, 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 les utilisateurs canadiens.

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

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, consultez le http://www.statcan.gc.ca/subjects-sujets/standard-norme/sgc-cgt/geography-geographie-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 point. 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 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.

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 de référence. 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 :

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 :

1. 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 d’un autre profil, l’identification des couches, les fonctions propres aux systèmes, etc.

Exemple :

(Référence à des profils multiples)
<alert>
…
<scope>public</scope>
<code>profile:CAP-CP:0.4</code>
<code>profile:IPAWS v1.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
Cette règle a été supprimée du PC-PAC, car elle est désormais mentionnée 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 de l’alerte au moment de diffuser le message.

Notes :

Exemple :

PC-PAC

É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 » ne change pas le message adressé au public; un bloc <info> est donc 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>

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 :

• 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.
• 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.
• 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.
• Le suffixe de version <valueName> change lorsque de 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. 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>

Utilisation : nécessaire

Type : technique

Valeur : La combinaison <valueName> et <value> du Lexique des localisations PC-PAC pour un code associé.

Description :

1. Le profil nécessite l'utilisation d'au moins une valeur de <geocode> du Lexique des localisations du PC-PAC pour les messages qui décrivent les régions du Canada. D'autres valeurs <geocode> d'autres systèmes de codes peuvent être utilisées en option avec le Lexique des localisations du PC-PAC.
2. Autant d'éléments <geocode> que nécessaire pour couvrir la totalité de la région visée du message d'alerte. Toutefois, quand il est possible d'utiliser un code plus élevé, il faut le faire.
3. Les codes de la Classification géographique type (CGT) de Statistique Canada servent de base au Lexique des localisations du PC-PAC
4. Le suffixe indiquant la version du <valueName> changera à mesure que de nouvelles versions du Lexique des localisations seront publiées. Les messages peuvent également mettre à profit la fonction d'utilisations multiples de l'élément <geocode> en incluant les codes de différentes versions du Lexique es localisations, afin d'assurer la rétrocompatibilité et de faciliter la transition entre les mises à jour de la liste.

Notes :

• Les géocodes sont inclus pour que tous les systèmes de distribution puissent transmettre des alertes, et pour d'autres fins comme la traduction. En temps voulu, l'utilisation obligatoire d'un géocode sera supprimée des règles du PC‑PAC.
• On recommande l'utilisation exclusive d'une unité territoriale de haut niveau et universelle qui s'applique entièrement à un message. Par exemple, si une région comprend tous les codes de subdivisions de recensement (SDR) d'une division de recensement (DR), il faut utiliser seulement le code de DR du niveau supérieur.
• Des codes de localisation supplémentaires d'autres listes, comme un CLC ou un code postal, peuvent être inclus (note : le CLC est un code de localisation de Radiométéo Canada).

Exemple :

(Dans l'exemple, le premier <geocode> renvoie à une division de recensement, tandis que le deuxième <geocode> renvoie à une subdivision de recensement, toujours dans le même bloc <info>)

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

(L'exemple qui suit renvoie à un <geocode> de deux lexiques de localisations. L'utilisateur doit indiquer, à partir de l'entrée <valueName>, le lexique qui répond à ses besoins.)

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

10. Les blocs <area> sont nécessaires

PAC

Élément : <area>

Utilisation : facultative

Type : technique

Valeur :

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

Notes :

Exemple :

PC-PAC

Élément : <area>

Utilisation : nécessaire

Type : technique

Valeur :

Description :

1. Un bloc <area> est nécessaire pour chaque bloc <info>.
2. Le PC-PAC exige qu'un bloc <area> contienne au moins une valeur <geocode>. On recommande d'ajouter une valeur géospatiale connexe comme <polygon> ou <circle> dans le bloc <area> également.
3. L'élément <areaDesc> décrit la région combinée des localisations énumérées et, comme l'élément <event>, il ne s'agit pas nécessairement d'un nom qui se trouve dans le Lexique des localisations.

Notes : Les descriptions des régions (comme les événements) devront être traduites par l'auteur du message dans les cas où le nom ne figure pas dans le Lexique des localisations.

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:0.3</valueName>
<value>2435040</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:0.3</valueName>
<value>2435027</value>
</geocode>
…
</area>
</info>

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

PAC

Élément : <sender>

Utilisation : nécessaire

Type : technique

Valeur : définie par l'utilisateur

Description : Identifie l'auteur du message d'alerte

Notes :

Exemple :

PC-PAC

É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, l'expéditeur (<sender>) est l'organisme provincial, et le nom de l'expéditeur (<senderName>) est la municipalité.
3. L'élément doit être le plus unique possible. Par exemple, un nom de domaine Internet faisant parti du <sender> est une façon de créer un nom unique.

Notes : Lorsqu'un fichier de message 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 d'Environnement Canada (EC) à Toronto a reçu de l'information d'alerte d'un autre bureau d'EC dans un format hors PAC et a par la suite reformaté les données en format PAC et redistribué le message. Dans ce cas, « Toronto » est un élément lisible par l'humain et « @ec.gc.ca » assure le caractère unique).

<sender>toronto@ec.gc.ca</sender>

(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>operation-center@EMO@gnb.ca</sender>

12. Un message de mise à jour ou d'annulation devrait au moins inclure des renvois à tous les messages actifs

PAC

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

PC-PAC

É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 <info block> actif n'a pas encore atteint la date et l'heure d'expiration (<expires>).
3. Dans le cas d'un bloc <info> qui n'a pas d'expiration, 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 assure que tous les messages qui sont encore erronés sont 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>

13. Une valeur <expires> est fortement recommandée

***REMARQUE : Tard dans le processus, on a reçu une demande pour qu'on réexamine cette règle et qu'on retire la recommandation. Dans la demande, on recommande de référer à la norme d'OASIS sur l'utilisation de <expires>, suggérant qu'elle y est déjà mieux expliquée quand on examine l'élément à utiliser pour l'ensemble des systèmes, des utilisateurs et des distributeurs. On fait valoir que le fait de forcer une valeur dans cet élément quand aucune n'est apparente, contrairement à l'annulation ou la mise à jour d'un message en temps réel, pourrait entraîner une surabondance ou une insuffisance de messages d'alerte, induisant possiblement en erreur l'auditoire du message. Le Groupe de travail sur le PC-PAC appuie cette recommandation, mais on a décidé d'insérer la présente remarque plutôt que de retirer la règle, car les intervenants du PC-PAC dans son ensemble sont toujours aux prises avec cette question. Dans tous les cas, la règle n'est qu'une recommandation, et la valeur demeure optionnelle.

PAC

Élément : <expires>

Utilisation : facultative

Type : technique

Valeur :

Description : Date et heure d'expiration de l'information du bloc <info> dans le message d'alerte.

Notes : Si la date et l'heure ne sont pas fournies, chaque destinataire est libre d'établir sa propre politique pour déterminer la période de validité d'un message.

Exemple :

PC-PAC

Élément : <expires>

Utilisation : recommandé

Type : politique

Valeur :

Description : Il est fortement recommandé que cet élément soit rempli par les auteurs des messages d'alerte, afin d'indiquer aux distributeurs la période de validité prévue de l'information du bloc <info> d'un message d'alerte.

Notes :

• Seules des valeurs formatées appropriées de date et heure devraient être utilisées. N'utilisez pas une valeur par défaut comme 0, une série vide ou une entrée nulle, qui seraient invalides.
• Pour éviter toute fausse interprétation, lorsque le délai d'expiration est inconnu, l'élément <expires> ne devrait pas être inclus du tout dans le message.

Exemple :

(Message ayant un délai d'expiration formaté correctement)

<alert … >
…
<info>
…
<expires>2008-01-01T07:00:00-00:00</expires>
…
</info>
…
</alert>

(Formats invalides)
<expires></expires>
<expires>NULL</expires>
<expires>0</expires>
<expires>0000-00-00T00:00:00-00:00</expires>
<expires>2008-01-01T07:00:00</expires>  (fuseau horaire manquant)
<expires>""</expires>

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

PAC

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

PC-PAC

Élément : <senderName>

Utilisation : recommandé

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>Environnement Canada</senderName>
..
</info>

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

PAC

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

PC-PAC

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

16. Indiquer lorsqu'un message de mise à jour comporte des modifications de contenu non essentielles.

PAC

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

PC-PAC

Élément : <parameter>

Utilisation : recommandée

Type : politique

Valeur : Une valeur <valueName> de « profile:CAP-CP:0.4:MinorChange » et une valeur <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 : 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:0.4:MinorChange</valueName>
<value>correction</value>
</parameter>
…
<area>
<areaDesc>Sainte-Anne-de-la-Pérade</areaDesc>
</area>  
</info>
</alert>

17. Indiquer la traduction automatisée du texte libre

PAC

Élément : <parameter>

Utilisation :

Type :

Valeur :

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

Notes :

Exemple :

PC-PAC

Élément : <parameter>

Utilisation : facultative

Type : politique

Valeur : Une valeur <valueName> de « profile :CAP-CP :0.4 :AutoTranslated » et une valeur <value> de « 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/ont été autotraduits.

Exemple :

(Dans l'alerte qui suit, la description a été générée en anglais par un logiciel interprétant 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 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:0.4: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.

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

PAC

Élément : <area>

Utilisation : optionnelle

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> et/ou <geocode>. Si les éléments multiples <polygon>, <circle> et/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 valeurs de la Classification géographique type utilisées dans le CP‑PAC.

Exemple :

PC-PAC

Élément :

Utilisation : optionnelle

Type : technique

Valeur :

Description :
Le PC-PAC exige une valeur <geocode>, et encourage l'utilisation des valeurs optionelles <polygon> et <circle>. Lorsque les valeurs <polygon> ou <circle> sont présentes dans un bloc région, la combinaison des valeurs <polygon> et <circle> est la représentation la plus exacte de la région d'alerte. Cela va à l'encontre de ce qui est actuellement défini dans le PAC, qui désigne la région comme étant la combinaison des valeurs <geocode>, <polygon> et <circle>.

Notes : La(les) région(s) associée(s) avec le <geocode> est(sont) souvent beaucoup plus vaste que la région d'alerte ciblée, ce qui donne lieu à une suralerte. Cette règle, selon sa définition actuelle, soutient une représentation plus exacte de la région d'alerte, tout en appuyant aussi l'inclusion obligatoire (du PC-PAC) du <geocode> dans un message du PC-PAC. Les utilisateurs du système qui peuvent soutenir l'identification plus exacte du lieu qui vient avec les éléments <polygon> et <circle> sont encouragés à le faire. 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:0.3</valueName>
<value>2435040</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:0.3</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.

Date de modification :

2018-01-31