There are only two hard things in Computer Science:
cache invalidation and naming things.
Phil Karlton
Probabilmente l’engineer di Netscape pensava proprio alle variabili usate per il codice fiscale:
cod_fisc, CF, cod_fiscale, codiceFiscale, codice_fiscale, fiscalCode , cfiscale
Quando queste - piccole - differenze si riflettono sulla codifica dei dati (eg. serializzazione/marshalling) impattano sui costi di interoperabilità ed anche di sviluppo.
Se due servizi serializzano differentemente i dati personali
Servizio A
{ 'nome_proprio': 'Mario',
'cognome': 'Rossi',
'codice_fiscale': 'RSSMRA30A01H501I'
}
Servizio B
{ 'nome': 'Mario',
'cognome': 'Rossi'
'cf': 'RSSMRA30A01H501I'
}
per interoperare ogni servizio deve aggiungere delle funzioni di conversione ed i relativi metodi di test.
Le Linee Guida Nazionali per la Valorizzazione del Patrimonio Informativo Pubblico forniscono una strategia per i nomi delle variabili e la serializzazione degli oggetti.
Ad esempio, questo file definisce i campi di una persona e fornisce un riferimento parlante per i nomi dei campi sia in inglese che in italiano.
Di seguito alcuni esempi in camelCase e snake_case:
- givenName, given_name, nomeProprio, nome_proprio
- familyName, family_name, cognome, cognome
- dateOfBirth, date_of_birth, dataDiNascita, data_di_nascita
- taxCode, tax_code, codiceFiscale, codice_fiscale
Come suggerito in Profilo metadatazione DCAT-AP_IT
vanno evitati acronimi ed abbreviazioni incomprensibili.
Ecco altre utili indicazioni per costruire servizi interoperabili:
- utilizzare UTF-8
- utilizzare ISO4217:alpha-3 (eg. EUR, USD, GBP, …) per le monete, come in fatturaPA
- utilizzare ISO 3166-1-alpha2 (eg. IT, US, DE) per i paesi