# Statistiche SPID: Tracciati Record

**URL:** <https://forum.italia.it/t/statistiche-spid-tracciati-record/15546>\
**Category:** Linee guida statistiche SPID\
**Created:** [7 Luglio 2020, 5:48pm UTC](https://forum.italia.it/t/statistiche-spid-tracciati-record/15546 "2020-07-07T17:48:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![walter-arrighetti](https://forum.italia.it/user_avatar/forum.italia.it/walter-arrighetti/32/121_2.png) [@walter-arrighetti](https://forum.italia.it/u/walter-arrighetti)\
**Post date:** [7 Luglio 2020, 5:48pm UTC](https://forum.italia.it/t/statistiche-spid-tracciati-record/15546/1 "2020-07-07T17:48:50Z")

</div>

> **[Statistiche SPID | 9. Tracciati record](https://docs.italia.it/AgID/documenti-in-consultazione/lg-spid-statistiche-docs/it/public-consultation/all/tracciati_record.html)**
>
> Linee Guida contenenti le Regole Tecniche per le Statistiche SPID

---

<div class="post-metadata">

**Author:** ![Roberto\_Polli](https://forum.italia.it/user_avatar/forum.italia.it/roberto_polli/32/1127_2.png) [@Roberto\_Polli](https://forum.italia.it/u/Roberto_Polli)\
**Post date:** [6 Agosto 2020, 1:49pm UTC](https://forum.italia.it/t/statistiche-spid-tracciati-record/15546/2 "2020-08-06T13:49:05Z")

</div>

Le Linee Guida d’Interoperabilità indicano dei criteri per i nomi dei campi ed i relativi formati. Sono una serie di accorgimenti che - se non adottati - possono creare confusione nel processamento dei formati. Per evitare il problema del casing (maiuscolo/minuscolo) potrebbe aver senso considerare snake\_case (eg. EntityID, Entityid, EntityId -\> entity\_id)  
Tra le altre cose:

- se si parla di timestamp, l’utilizzo di questa forma di ISO8601 mi pare poco interoperabile `2020-01-15T15Z` ed userei invece il profilo indicato in RFC3339 `2020-01-15T15:00:00Z`.

- se lo stile dei campi è camelCase, lo userei in maniera consistente, eg: se il campo SAML si chiama `entityID` eviterei di far iniziare tutti i campi con la maiuscola. Alcuni hanno nomi diversi, eg. `SP3.1: EntityID`, `SP2.1: EntityId`, `AA1.2: Entityid`. Il case di `AA1.1: AAid` non è chiaro.

- il campo `DomicilieCode` potrebbe essere un typo, eg: `Domicile` senza `i`.

- riorganizzerei i nomi dei campi, un po’ criptici o dove non è chiaro il criterio. La difficoltà di individuare un nome potrebbe essere uno spunto per riflettere sul dato campionato (la mia proposta di naming è parimenti non entusiasmante) eg:  
NrProcAuth # autenticazioni L1 e L2 -\> AuthenticationCount\_L1L2  
NrProcReg # registrazioni L1 e L2 -\> RegistrationCount\_L1L2  
NrProc # registrazioni e autenticazioni L3 -\> TotalCount\_L3

- per indicare quadrimestre, trimestre & co potrebbe essere utile utilizzare il formato data indicante il primo giorno del trimestre (eg. 2020-01-01, 2020-04-01) in modo da avere le date ordinabili e potere in caso di necessità modificare la semantica del campo senza variare il formato. La specifica ISO8601 usa per i quadrimestri il formato YYYY-MM con MM nell’intervallo 33-36 e imho non è particolarmente intuitivo.
