Comments (14)
@p4535992 non sono un legal, io utilizzerei la PEC di AgID
from protocollo-comunicazione-aoo.
@vintra73 scusa il riferimento diretto , ma avremmo urgenza di risolvere la problematica. Puoi farci sapere niente ?
from protocollo-comunicazione-aoo.
Scusami per il ritardo, in merito all'XSD da te indicato https://github.com/AgID/protocollo-comunicazione-aoo/blob/master/previous_schemas/segnatura_protocollo_circolare%2060_2013.xsd abbiamo ricopiato il contenuto riportato in
https://www.agid.gov.it/sites/default/files/repository_files/circolari/circolare_60_2013_segnatura_protocollo_informatico_-_rev_aipa_n.28-2001.pdf
Riscontri un disalineamento con la circolare CIRCOLARE AgID N. 60 DEL 23 GENNAIO 2013? Se si puoi indicarmi dove cosi provvedo al fixing sul presente repo.
Grazie
from protocollo-comunicazione-aoo.
@vintra73 Guarda noi abbiamo dei clienti che hanno degli xml 2013 come quello indicato (vedi xml in chiaro nella prima risposta) dove nel parametro della "versione" mettevano la data in formato "aaaa-mm-gg" e.g. 2013-01-23 come previsto dalla circolare da te indicata (che è la stessa che mi era stata indicata) , dal punto di vista del codice sembra invece che l'XSD voglia il valore fisso della stringa "aaaa-mm-gg" che è errato (almeno secondo me).
Si tratta di un problema di carattere "tecnico", passando gli xml 2013 sull' xsd https://github.com/AgID/protocollo-comunicazione-aoo/blob/master/previous_schemas/segnatura_protocollo_circolare%2060_2013.xsd sempre del 2013 per una validazione di sicurezza ci viene un'errore cvc-complex-type.3.1: Value '2013-01-23' of attribute 'versione' of element 'Segnatura' is not valid with respect to the corresponding attribute use. Attribute 'versione' has a fixed value of 'aaaa-mm-gg'.
Puoi verificare con dei tool online come questo https://www.liquid-technologies.com/online-xsd-validator, l'xml ci risulta corretto, ma l'xsd ci dice che non lo è, per far passare il controllo dobbiamo sostituire la stringa "2013-01-23" con "aaaa-mm-gg".
E' una cosa che possiamo "gestire" modificando leggermente l'xsd o semplicemente settando il valore "aaaa-mm-gg" sugli xml prima della validazione, ma vorremmo avere una risposta "ufficiale" in merito alla problematica (se è una problematica si intende).
from protocollo-comunicazione-aoo.
A chiunque possa interessare non avendo ricevuto una risposta ufficiale in nessun messaggio o post abbiamo modificato la validazione del campo versione
rimuovendo type="xs:NMTOKEN" fixed="aaaa-mm-gg"
e sostituendolo con type="xs:date"
che dovrebbe essere a mio giudizio il controllo corretto.
from protocollo-comunicazione-aoo.
Se posso intromettermi, tieni conto che dall'altro lato potresti avere qualcuno che ha aggirato l'evidente errore dell'XSD scrivendo proprio "aaaa-mm-gg" nella segnatura (se riesco voglio fare qualche prova a campione su cosa riceviamo noi).
Penso comunque che più che un xs:date generico penso che dovrebbe essere una lista di possibili valori (non so quante versioni di schema di segnatura esistano).
from protocollo-comunicazione-aoo.
@franthemanIT Guarda io sono ignorante per quanto riguarda la burocrazia italiana, ma nella circolare (quella linkata da @vintra73 ) c'e' scritto chiaramente L'attributo "versione" ha valore fisso, pari alla data di pubblicazione, espressa in formato ISO 8601 esteso (i.e. aaaa-mm-gg).
che io traduco in:
- Deve essere una data (quindi non una stringa in formato
"aaaa-mm-gg"
) - Deve essere in formato ISO 8601 esteso cioè in uno dei seguenti formati
YYYY-MM-DD
,YYYY-MM-DDThh:mm<TZDSuffix>
,YYYY-MM-DDThh:mm:ss<TZDSuffix>
- La circolare specifica chiaramente che il formato della "data" deve essere "aaaa-mm-gg" ovvero il formato internazionale
YYYY-MM-DD
(e con questo si esclude qualsiasi dubbio in merito alla scelta se usaretype="xs:date"
otype="xs:dateTime"
può essere solo untype="xs:date"
.)
Qualsiasi consiglio o suggerimento è ben accetto.
from protocollo-comunicazione-aoo.
Concordo pienamente. Però, se ho ben capito;
- l'XSD pubblico che è quello che fa fede e che i software dovrebbero implementare per validare gli XML della segnatura non è conforme alla circolare (e, diciamolo, un attributo fisso "aaaa-mm-gg" tanto vale non metterlo nemmeno);
- tu, per sopravvivere, lo hai corretto e lo hai reso conforme alla circolare;
- altri usano l'XSD originale e bollano come non valida una segnatura che usa una data vera;
- chi compone la segnatura, per essere conforme all'XSD pubblico, probabilmente si adegua all'insensato "aaaa-mm-gg"...
La modifica che hai fatto all'XSD come considera la segnatura con "aaaa-mm-gg"? Adesso non ne trovo una, sono tutte "versioni nuove da allegato 6", ma sono sicuro di averne viste passare...
from protocollo-comunicazione-aoo.
Quindi una cosa del genere:
<xs:simpleType name="DateVersioneAgidType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]{4}-[0-9]{2}-[0-9]{2}|aaaa\-mm\-gg"/>
</xs:restriction>
</xs:simpleType>
per accettare sia "2023-03-13" che "aaaa-mm-gg" e sostituire type="xs:NMTOKEN" fixed="aaaa-mm-gg"
con type="DateVersioneAgidType"
sarebbe piu' coerente ? Immagino di si e male non fa credo... c'è comunque un pò di confusione...
from protocollo-comunicazione-aoo.
Eh, il punto e' che se c'e' un XSD autoritativo andrebbe usato quello e stop. Se ha un errore materiale al suo interno arrivano i problemi a cascata.
La soluzione di creare quel simpleType potrebbe essere una toppa. Oppure istruire il software che se la validazione fallisce per via del "aaaa-mm-gg" andare avanti comunque.
Pero'. non voglio prendermi responsabilità, invitavo solo a valutare gli effetti della modifica unilaterale dello schema di validazione. AgID saprà dare indicazioni piu' serie.
Fra l'altro, le segnature sono piene di errori formali. Scartarle tutte automaticamente rischia di paralizzare le comunicazioni, ma questa è un'altra storia.
from protocollo-comunicazione-aoo.
Sono d'accordo il punto che io cerco qualcuno di "ufficiale" che mi metta nero su bianco che si deve usare effettivamente la stringa "aaaa-mm-gg" pechè la circolare mi dice effettivamente che è una data non una stringa (per quanto sia un'errore a livello tecnico secondo me), in modo da dire al cliente che per tutto questo tempo ha sbagliato lui a mettere le date come "2023-13-01" nell'attributo versione dell'xml perchè ha "interpretato" male la circolare...
from protocollo-comunicazione-aoo.
scusami @p4535992, volevo ricordarti che questo non è un canale ufficiale, dovresti porre un quesito ad AgID sull'interpretazione della CIRCOLARE N. 60 DEL 23 GENNAIO 2013 tramite i canali ufficiali.
from protocollo-comunicazione-aoo.
@vintra73 mi sapresti dare un link al sito o un'email per questo tipo di domanda ? di questa parte purtroppo se sono occupate altre persone che non mi hanno fatto sapere niente, se hanno fatto queste identiche domande (se le hanno fatte) e sono in attesa di una risposta io purtroppo non lo so.
Ho trovato dei contatti, ma non sono sicuro se sono i canali corretti, per questo genere di domande va bene scrivere a [email protected] ?
from protocollo-comunicazione-aoo.
A chiunque sia interessato nessuno mi ha mai risposto in merito alla problematica, che rimane tutt'ora irrisolta
from protocollo-comunicazione-aoo.
Related Issues (20)
- Link WebService su IndicePA HOT 1
- Casi di segnature ricevute senza dati obbligatori - impronta non corrispondente e ditte individuali HOT 1
- Rapporto tra data di apposizione del sigillo sul file Segnatura.xml e data di protocollo
- Servizio per validazione segnatura rispetto ai file inviati HOT 1
- URL/URI dei namespace HOT 1
- Proposta per verifica stato di adeguamento alla nuova segnatura
- Numero di mittenti nella segnatura di protocollo HOT 1
- Quesito su allegato 6 - memorizzazione della conferma di protocollazione del messaggio di protocollo nel registro di protocollo HOT 1
- Richiesta di intervento a salvaguardia delle comunicazione fra AOO
- Data del sigillo e data del protocollo: richiesta di renderle indipendenti
- mittente / destinatario HOT 2
- La segnatura XML HOT 1
- bearerAuth e PDND HOT 2
- Esposizione dei servizi di interoperabilità tra protocolli informatici HOT 6
- NON TECNICO: proposta di intenti HOT 2
- Allegato 6 & PDND HOT 2
- Chiarimenti su comunicazioni PEC e WS HOT 1
- Segnatura.xml e protocollo REST
- Prospettive uso API via PDND HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protocollo-comunicazione-aoo.