Statistiche SPID: Tracciati Record

Consultazioni pubbliche Linee guida statistiche SPID
1
2

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.

1 Mi Piace