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-15T15Zed userei invece il profilo indicato in RFC33392020-01-15T15:00:00Z. -
se lo stile dei campi è camelCase, lo userei in maniera consistente, eg: se il campo SAML si chiama
entityIDeviterei 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 diAA1.1: AAidnon è chiaro. -
il campo
DomicilieCodepotrebbe essere un typo, eg:Domicilesenzai. -
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.