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

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 adresse 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 du document :

• Doug Allport, Association canadienne d’avis et d’alerte au public/Allport Group Inc.
• Paul Buck, Sécurité publique Canada
• April Diver, Alberta Emergency Management Agency
• Khalil Hayek, Ressources naturelles Canada
• Kathleen McCrae, Sécurité publique Canada
• David Parry, Association canadienne d’avis et d’alerte au public/Telus
• Norm Paulsen, Environnement Canada
• Valerie Plaskacz, Industrie Canada
• Jacob Westfall, Net Alerts
• Wendy Wu, Industrie Canada

Droits d’auteur

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

Avis

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

Sommaire des révisions

Le présent document comprend les révisions majeures qui suivent, apportées à l’ébauche publique no 2 (version du 8 mai 2008), telle que publiée par Industrie Canada :

1. Beta 0. 3 maintient l’exigence en ce qui concerne un type d’événement par fichier d’alerte, sans imposer la limite d’un segment d’information par langue et par fichier d’alerte.
2. Beta 0. 3 renvoie à des listes gérées qui viennent d’être établies ou reconnues, ainsi qu’à l’ensemble de règles défini ci-après, des outils qu’il faut utiliser parallèlement au PC-PAC.

Autres documents PC-PAC

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

1. Lexique des événements du PC-PAC. Ce document précise une liste compréhensive d’événements associés avec les alertes publiques au Canada.
2. Lexique des emplacements du PC-PAC: Ce document décrit les versions actuelles de la terminologie des emplacements de la Classification géographique type (CGT) appuyée par le PC-PAC.

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

• Association canadienne d’avis et d’alerte au public (ACAAP) - www.CAPAN.ca/CAP-CP
• Environnement Canada – à confirmer
• Industrie Canada - à confirmer
• Ressources naturelles Canada - à confirmer
• Sécurité publique Canada – à confirmer

Alberta Emergency Management Agency

• - http://www.aema.alberta.ca/ps_emergency_public_warning_system.cfm

Le PC-PAC peut également se retrouver sur d’autres sites Web. Si des différences existent entre les versions, la version au www.CAPAN.ca/CAP-CP aura la priorité. Des nouvelles versions seront créées seulement avec la permission expresse des auteurs énumérés dans ce document.

Documents associés et ressources

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

Terminologie normative

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

Le PC-PAC adopte la terminologie de la norme de référence. En outre,

Le terme « couche » (layer) est utilisé dans le présent document pour désigner les éléments qui ne sont pas nécessaires en vertu de la norme de référence ou du PC-PAC, mais qui peuvent se rapporter à une nouvelle règle, à d’autres listes gérées et/ou à de l’information propre à un sous-ensemble d’utilisateurs de la communauté des alertes au public du Canada. Une couche est habituellement soutenue par l’utilisation d’au moins un élément de paramètre dans un fichier du PAC ou du PC-PAC. Comme l’information qui se trouve dans une couche est à l’extérieur de la portée du PC-PAC, elle n’est pas gérée comme partie du PC-PAC; toutefois, l’ACAAP tiendra une liste des couches connues pour soutenir les utilisations non conflictuelles des noms de balises. Les auteurs des couches sont encouragés à s’identifier au Comité de surveillance.

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 fichier du PC-PAC (par exemple, la liste des événements du PC-PAC).

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

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

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

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

Introduction

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 1} (PPW) des É.-U.

En 2004, le PAC est devenu une norme de l’Organization for the Advancement of Structured Information Standards (OASIS). Une révision a été publiée en octobre 2005. En décembre 2006, l’Union internationale des télécommunications (UIT) a adopté la version 1.1 du PAC comme recommandation UIT-T.

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. Selon la vision, le PAC devrait être adopté comme norme nord-américaine et utilisé dans le système proposé d’alerte au public à l’échelle du Canada, qui s’appelait à l’époque CANALERT.

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

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

Environnement Canada a également créé un processus de mise en œuvre des références du PC-PAC, afin de diriger la discussion sur l'interprétation du PAC et du PC-PAC au Canada. Cette procédure de mise en œuvre des références aidera les intervenants à comprendre les différences d'interprétation et devrait améliorer, dans l'ensemble, l'intégrité de chacun des systèmes visés.

Aperçu du PC-PAC

L'ébauche publique no 3 du PC-PAC s'attarde principalement à trois exigences et une contrainte de premier plan :

1. Limite d'un événement par fichier d'alerte
2. Exigences linguistiques
3. Exigences associées à la détermination des événements
4. Exigences associées à la détermination des emplacements

De plus, quelques règles secondaires sont en place 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 et l'ébauche de mai 2008 du PC-PAC.

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. Limite d'un événement par fichier d'alerte.

La norme de référence permet l'inclusion de plusieurs événements dans un seul fichier d'alerte, mais elle précise qu'un seul identificateur de fichier unique 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 fichier d'alerte, même s'il n'y a aucun changement à signaler pour les autres événements.

De plus, étant donné que les valeurs des événements seront utilisées à des fins de filtrage, d'acheminement, de validation et d'autres besoins au sein de la communauté, les systèmes auraient du mal à traiter un fichier 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 fichier 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, l'utilisation de la valeur linguistique est très importante pour les distributeurs de messages lorsqu'il y a deux langues officielles.

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

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

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

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

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

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

La norme de référence permet l'utilisation d'une description textuelle, de cercles et de polygones du SIG, ainsi que l'utilisation de codes d'emplacements géoréférencés pour décrire 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 d'emplacements géoréférencés doivent être utilisés pour les emplacements 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 emplacements 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 d'emplacements géopolitiques. Le système de la CGT fournit des codes numériques uniques pour trois types de régions géographiques : provinces et territoires; divisions de recensement (DR), comme les comtés et les municipalités régionales; et subdivisions du recensement (SDR), comme les villes, les villages et les cantons. Pour de plus amples renseignements sur la CGT de 2006, visitez le http://www.statcan.gc.ca/subjects-sujets/standard-norme/sgc-cgt/2006/2006-ind-fra.htm

La liste d'emplacements 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.

En date de mai 2009, 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.

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). Elle ne devrait pas non plus suggérer que des moyens plus précis d'identification des emplacements, comme les polygones du SIG, ne sont pas encouragés.

Règles du PC-PAC

La présente section énonce les exigences, les contraintes et les recommandations spécifiques 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.

Définitions des éléments du tableau

Élément : élément PAC-XML, tel que décrit dans la norme du PAC 1.1.
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 au PAC, 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 le contenu de l'élément « valueName » est une chaîne affectée par l'utilisateur désignant le domaine du code, et que les valeurs de « valueName » qui correspondent à un acronyme DEVRAIENT figurer en majuscules sans points. La norme ne formule aucune autre recommandation en ce qui concerne la création d'un <valueName> et la détermination du domaine du code ou de son format. Le <valueName> devrait identifier de façon unique la liste des valeurs utilisée et, lorsque l'on prévoit apporter des changements à la liste de valeurs, il devrait offrir une façon de permettre les modifications en identifiant chaque révision individuelle.

Les spécifications subséquentes du comité d'Oasis qui a établi le PAC sont fondées sur un <valueListUrn> au lieu d'un <valueName>, et on présume que les versions à venir du PAC feront de même. Un nom de ressources uniforme (URN) est un Identificateur de ressources uniformes (URI) décrit dans RFC 1737. 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é. 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.

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

PAC

Élément : s.o.

Utilisation :

Type :

Valeur :

Description : La norme de référence

Notes :

Exemple :

PC-PAC

Élément : s.o.

Utilisation : nécessaire

Type : politique

Valeur :

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

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

Exemple :

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

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

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

PAC

Élément : s.o.

Utilisation :

Type :

Valeur :

Description :

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

Exemple :

PC-PAC

Élément : s.o.

Utilisation : nécessaire

Type : politique

Valeur :

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

Notes :

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

Exemple :

(Acceptable)

<alert …>
…
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>CDNevent:1.0</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 1</areaDesc>
<geocode>…</geocode>
</area>
</info>
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>CDNevent:1.0</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 2</areaDesc>
<geocode>…</geocode>
</area>
</info>

(Inacceptable)

<alert …>
…
<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>CDNevent:1.0</valueName>
<value>thunderstorm</value>
</eventCode>
…
<area>
<areaDesc>area 1</areaDesc>
<geocode>…</geocode>
</area>
</info>
<info>
…
<event>Tornado</event>
…
<eventCode>
<valueName>CDNevent:1.0</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 : Valeur, indicateur ou code spécial définis par l’utilisateur 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:1.0 »

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

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

Exemple :

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

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

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

</alert>
…
<scope>public</scope>
<code>profile:CAP-CP:1.0</code>
<code>profile:EC:1.0</code>
<note></note>
…

4. Le champ du fuseau horaire doit être inclus dans toutes les variables temporelles

PAC

Élément : <sent>, <expires>, <onset>, <effective>

Utilisation :

Type : technique

Valeur : format dateTime

Description : Il ne faut pas utiliser d’indicateurs de fuseaux horaires alphabétiques, comme Z. Le fuseau horaire pour l’UTC doit être représenté comme -00:00 ou +00:00.

Notes : Le PAC établit une exigence de format pour le champ du fuseau horaire, mais il n’exige pas sa présence.

Exemple :

<sent>2008-07-16T20:00:00-00:00</sent>
..ou...
<sent>2008-07-16T20:00:00</sent>

Ces deux format sont aussi valides l’un que l’autre conformément à la spécification du PAC.

PC-PAC

Élément : <sent>, <expires>, <onset>, <effective>

Utilisation : nécessaire

Type : technique

Valeur : format dateTime

Description : Le champ du fuseau horaire est nécessaire pour éliminer la fausse interprétation des heures en cause en fonction des fuseaux horaires.

Notes :

1. Ce point tient compte d’une omission reconnue dans la norme du PAC.
2. Nous reconnaissons que l’utilisation de l’heure locale pose une difficulté dans les présentations des distributeurs, qui peut être résolue au moyen de la politique propre au système (par exemple, une politique de système pourrait stipuler que l’information sur le fuseau horaire doit être incluse, suivant la région citée dans le bloc <area>, y compris la condition relative à l’heure avancée).

Exemple :

(Acceptable)
<alert …>
…
<sent>2008-07-16T20:00:00-00:00</sent>
<status>Actual</status>
…
<info>
…
<effective>2008-07-16T20:00:00-00:00</effective>
<onset>2008-07-16T20:30:00-00:00</onset>
<expires>2008-07-17T06:00:00-00:00</expires>
…
</info>
…
</alert>

(Politique propre au système – dans ce cas-ci, -02 :30 représente Terre-Neuve-et-Labrador pendant la période d’heure avancée)
<alert …>
…
<sent>2008-07-16T20:00:00-00:00</sent>
<status>Actual</status>
…
<info>
…
<effective>2008-07-16T20:00:00-02:30</effective>
<onset>2008-07-16T20:30:00-02:30</onset>
<expires>2008-07-17T06:00:00-02:30</expires>
…
<area>
<areaDesc>Newfoundland and Labrador</areaDesc>
…
</area>
</info>
…
</alert>

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

PAC

Élément : <msgType>

Utilisation : nécessaire

Type : politique

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

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

Notes :

Exemple:

CAP-CP

Élément : <msgType>

Utilisation : nécessaire

Type : politique

Valeur :

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

1. Pour les messages d’alerte à distribuer au public, l’élément <msgType> des valeurs « Alert », « Update » ou « Cancel » ne change pas l’état du message, et un bloc <info> est nécessaire.
2. Pour les messages d’alerte ayant un <msgType> « Ack » ou « Error », un bloc d’information n’est pas nécessaire, puisque ces 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>CAP-CPv1.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>CAP-CPv1.0</code>
<note />
<references />
<incidents />
</alert>

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

PAC

Élément : <language>

Utilisation : facultatif

Type : politique

Valeur : définie par RFC 3066

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

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

Exemple :

PC-PAC

Élément : <language>

Utilisation : nécessaire

Type : technique

Valeur :

Description :

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

Notes :

1. Les valeurs correspondantes de RFC 3066 pour anglais et français du Canada sont « en-CA » et « fr-CA ». Un message peut être transmis dans d’autres langues parlées au Canada, et les valeurs appropriées devraient être utilisées.
2. UTF-8 est le code 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, qui apparaissent souvent comme un mot dans une langue donnée, sont utilisées aux fins du traitement logiciel seulement, et non pas pour affichage, et ne sont pas traduites d’un bloc <info> à l’autre (c.-à-d. <category>, <urgency>, <severity>, <certainty>, <responseType>, etc…)

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. Un tableau de consultation énumérant les articles pour chaque événement dans le Lexique des événements sera diffusé.

Exemple :

<info>
…
<event>Thunderstorm</event>
…
<eventCode>
<valueName>urn:capcp:CDNevent:1.0</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 : code du Lexique des événements du PC-PAC.

valueName> : « CAP-CP:Event:X.X », où X.X indique la version du Lexique des événements utilisée.

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 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:1.0</valueName>
<value>thunderstorm</value>
</eventCode>
<eventCode>
<valueName>profile:EC:SAME:1.0</valueName>
<value>SVR</value>
</eventCode>

…
</info>

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

PAC

Élément : <geocode>

Utilisation : facultative

Type : technique

Valeur : définie par l’utilisateur.

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

Notes : L’élément <geocode> est déprécié dans la version 1.1 du 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 : code du Lexique des emplacements du PC-PAC

L’élément <valueName> est « CAP-CP:Location:X.X », où X.X indique la version du Lexique des emplacements utilisé.

Description :

1. Le profil nécessite l’utilisation d’au moins une valeur de <geocode> du Lexique des emplacements 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 emplacements du PC-PAC.
2. L’élément <geocode> permet les utilisations multiples dans un message du PAC, et il faut utiliser autant d’éléments de <geocode> que nécessaire pour couvrir la totalité de la région visée du message d’alerte.
3. Les codes de la Classification géographique type (CGT) de Statistique Canada servent de base au Lexique des emplacements du PC-PAC
4. Le suffixe indiquant la version du <valueName> changera à mesure que de nouvelles versions du Lexique des emplacements 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 de la Liste des emplacements, afin d’assurer la rétrocompatibilité et de faciliter la transition entre les mises à jour de la liste.

Notes :

1. 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.
2. Des codes d’emplacements supplémentaires d’autres listes, comme un CLC ou un code postal, peuvent être inclus à d’autres fins (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:1.0</valueName>
<value>3506</value>
</geocode>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>3507004</value>
</geocode>
</area>
</info>

(L’exemple qui suit renvoie à un <geocode> de deux listes d’emplacements. L’utilisateur doit indiquer, à partir de l’entrée <valueName>, la liste qui répond à ses besoins.)

<info>
<area>
<geocode>
<valueName>profile:CAP-CP:Location:1.0</valueName>
<value>3506</value>
</geocode>
<geocode>
<valueName>profile:Postal:Location:1.0</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. Étant donné que le code d’emplacement est un élément nécessaire, un bloc <area> ayant une <areaDesc> appropriée doit être inclus dans tous les blocs <info>.
2. On recommande d’inclure une valeur géospatiale connexe pour les éléments <polygon> ou <circle> dans le bloc <area> également.
3. L’élément <areaDesc> décrit la région combinée des emplacements énumérés (géocodes) et, comme l’élément <event>, il ne s’agit pas nécessairement d’un nom qui se trouve dans les documents de référence sur les emplacements.

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 la liste de référence reconnue.

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>

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, éventuellement 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 comme <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 s’aligner à l’agrégateur. De préférence, l’élément <identifier> du message original sera ajouté à l’élément <incidents>, et une <note> sera ajoutée pour indiquer les changements.
L’utilisation d’un format comme le nom de domaine assure le caractère unique, mais il devrait y avoir une liste générée par le système à la disposition de tous les utilisateurs indiquant tous les noms et coordonnées (surtout si le domaine n’est pas vraiment un domaine Internet)

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

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 <info block> 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 et/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 au 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

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 :

1. 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.
2. 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 : Shelter | Evacuate | Prepare | Execute | Monitor | Assess | None

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 fortement 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. Indiquez 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 <msgType> de la mise à jour 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 : « none », « text », « correction », « resource », « layer » ou « other ».

L’élément <valueName> est « CAP-CP:1:0:MinorChange ».

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 est ajouté, modifié ou supprimé 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 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 non essentiel 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>

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 : « yes » ou « no »

L’élément <valueName> est : « CAP-CP:1.0:AutoTranslate ».

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.

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>
…
<description>Take precautions as threatening or hazardous conditions arrive.
</description>
<parameter>
<valueName>profile:CAP-CP:1.0:AutoTranslate</valueName>
<value>Yes</value>
</parameter>
…
</info>
</alert>

Date de modification :

2022-08-16