Validazione file xml della Fattura elettronica non va più

[Luigis]

Salve,
valido la fattura elettronica con questo codice:

//--------------- Load schema document ------------------------
SchemaDoc := CoDOMDocument60.Create;
SchemaDoc.async := False;
SchemaDoc.resolveExternals := True;
SchemaDoc.setProperty('ProhibitDTD', False);
SchemaDoc.load ( XmlFEXsdUrl );

//--------------- register schema cache- -----------------------
SchemaCache := CoXMLSchemaCache60.Create;
SchemaCache.add ( XmlFETargetNamespace, schemadoc); ************

//--------------- load data-- ----------------------
XmlDoc := CoDOMDocument60.Create;
XmlDoc.async := False;
XmlDoc.resolveExternals := True;
XmlDoc.loadXML(AXmlText);

//------ allocate the schema cache to the XML document ------------
XmlDoc.schemas := schemacache;

//--------------- Verification and Report -------------------------
Error := xmldoc.validate;

if Error.errorCode <> S_OK then
begin
Beep;
ShowMessage(smMsg + IntToStr(Error.line) + ': ' +
Error.Reason +
Error.SrcText);
end
else Result := true;

ma dal 01/09/2022 non funziona più perché, nell'eseguire la linea di
codice contrassegnata con gli asterischi, restituisce sempre l'eccezione:

"Durante il caricamento dello schema
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"
si è verificato il seguente errore: Accesso negato. Errore durante
l'elaborazione della risorsa "http://www.w3.org/2001/XMLSchema.dtd"

Non capisco cosa sia cambiato e come posso rimediare.

Se può essere di aiuto, il mio file xml inizia sempre così:

<?xml version="1.0" encoding="WINDOWS-1252"?>
<p:FatturaElettronica
xmlns:p="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2"
versione="FPR12">

Qualcuno può aiutarmi?

Grazie.

[Luigis]

Se può essere di aiuto:

SchemaDoc, XmlDoc: IXMLDOMDocument2;
SchemaCache: IXMLDOMSchemaCollection;

XmlFETargetNamespace =
'http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2';

XmlFEXsdUrl =
'https://www.fatturapa.gov.it/export/documenti/fatturapa/v1.2.1/Schema_del_file_xml_FatturaPA_versione_1.2.1a.xsd';

[Luigis]

Ho notato che la risorsa "http://www.w3.org/2001/XMLSchema.dtd" non
viene letta da "Internet Explorer" contenuto in Windows 10 ma viene
regolarmente letta da Edge e Firefox, non ne ho provati altri.

Ed in effetti leggo su W3.org che hanno imposto il redirect da http a https.

In rete ho trovato vari post che riguardano il problema del redirect su
url https di msxml6.0 ma non riesco a capire come modificare il codice
per risolvere il mio problema.

Qualcuno sa come impostare msxml6.0 per fargli digerire url https?

Grazie.

[Luigis]

Provando a dialogare con W3.org mi viene risposto che stanno eseguendo
un test, ancora in corso, per l'accesso a tutte le loro risorse via https.

Dicono di avere imposto delle eccezioni per i files .xsd ma per alcuni
stanno sperimentando dei problemi.

Consigliano di copiare i loro files in locale e utilizzare questi ma,
non saprei come fare.

Qualcuno ha già modificato il file .xsd dell'agenzia delle entrate
affinché lavorasse in locale?

Può, per favore, darmi delle dritte su come modificarlo?

Preliminarmente per vedere se funziona in locale ho provato a fare le
seguenti cose:
1) L'ho salvato in locale;
2) Ho modificato tutte le chiamate al sito W3.org impostando la chiamata
https.
3) con lo stesso codice postato nel primo post mi viene fuori il
seguente errore:
"Definizione non corretta dell'elemento di livello radice nello schema".

Non capisco...

Grazie.

[Alberto Salvati]

> Consigliano di copiare i loro files in locale e utilizzare questi ma,
> non saprei come fare.

Ripristina le chimate in http. Poi, questa:

"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"

presumibilmente, diventa questa:

"c:/pippo/pluto/xmldsig-core-schema.xsd"

Ovviamente (ma non per tutti) devi sostituire c:/pippo/pluto/ con il tuo path locale che contiene il kaz fi file "xmldsig-core-schema.xsd"...
Quell'informazione è un seplice path che può essere sia locale, sia in lan che in wan...
Solo, controlla bene la sintassi....ho scritto di getto e potrei aver scritto qualche cazzata....

A.

[Luigis]

Il problema è che salvando in locale il file ministeriale:
<Schema_del_file_xml_FatturaPA_v1.2.2.xsd> in locale, quando lo richiamo
tramite il codice già postato:
dove:
XmlFETargetNamespace =
'http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2';

XmlFEXsdUrl = 'c:\mi\Schema_del_file_xml_FatturaPA_versione_1.2.1a.xsd';

//--------------- Load schema document ------------------------
SchemaDoc := CoDOMDocument60.Create;
SchemaDoc.async := False;
SchemaDoc.resolveExternals := True;
SchemaDoc.setProperty('ProhibitDTD', False);
SchemaDoc.load ( XmlFEXsdUrl );

//--------------- register schema cache- -----------------------
SchemaCache := CoXMLSchemaCache60.Create;
SchemaCache.add ( XmlFETargetNamespace, schemadoc); ************

nella riga con gli asterischi, adesso l'errore riportato è:

"Definizione non corretta dell'elemento di livello radice nello schema"

Grazie.

[Luigis]

Il 06/09/2022 15:13, Luigis ha scritto:
>
> nella riga con gli asterischi, adesso l'errore riportato è:
> "Definizione non corretta dell'elemento di livello radice nello schema"
>

Scusa, rivedendo il file xsd mi accorgo che era rimasta un https,
ripristinato ad http, adesso funziona tutto in locale.

Chiedo per capise (se ci riesco): ma perché gli url di riferimento al
sito www.w3.org vanno lasciati così come l'url al sito dell'agenzia
delle entrate se poi i file utilizzati sono in locale?

Grazie.

[Alberto Salvati]

> Scusa, rivedendo il file xsd mi accorgo che era rimasta un https,
> ripristinato ad http, adesso funziona tutto in locale.

No...non è "tutto in locale".
In locale hai solo il riferimento al file xmldsig-core-schema.xsd che, alla fin fine, contiene DEFINIZIONI.
Avere questo file in locale non è il massimo..
Se w3 lo dovesse cambiare, tu in locale ne avresti una versione vecchia.
Questa è solo una soluzione TEMPORANEA in attesa che w3 sistemi le cose.

> Chiedo per capise (se ci riesco): ma perché gli url di riferimento al
> sito www.w3.org vanno lasciati così come l'url al sito dell'agenzia
> delle entrate se poi i file utilizzati sono in locale?

Prima di tutto non c'è nessun "vanno lasciati così"....
Tu punti a w3 per alcune cose (e w3 ti rompe 'o kaz...) e all'agenzia delle entrate per altre
NON C'E' NESSUN LEGAME TRA LE 2 COSE, infatti hai 2 url diversi.

Facciamo un esempio...
Fai la spesa.
Compri il pane in un posto e la frutta in un altro.
Il posto in cui prendi il pane lo trovi chiuso, quindi vai da un altro.
Ma tutto ciò non ha alcuna rilevanza su dove compri la frutta....

A.

[Luigis]

Il 06/09/2022 16:44, Alberto Salvati ha scritto:
>
>> Scusa, rivedendo il file xsd mi accorgo che era rimasta un https,
>> ripristinato ad http, adesso funziona tutto in locale.
>
> No...non è "tutto in locale".
> In locale hai solo il riferimento al file xmldsig-core-schema.xsd che, alla fin fine, contiene DEFINIZIONI.

Si, per locale intendevo questo.

> Avere questo file in locale non è il massimo..
> Se w3 lo dovesse cambiare, tu in locale ne avresti una versione vecchia.
> Questa è solo una soluzione TEMPORANEA in attesa che w3 sistemi le cose.
>

In una risposta che mi hanno inviato loro stessi (w3.org) consigliano di
modificare i files .xsd affinché lavorino con copie locali dei loro files.

>
>> Chiedo per capise (se ci riesco): ma perché gli url di riferimento al
>> sito www.w3.org vanno lasciati così come l'url al sito dell'agenzia
>> delle entrate se poi i file utilizzati sono in locale?
>
> Prima di tutto non c'è nessun "vanno lasciati così"....

Mi accorgo che mi esprimo da cani: intendevo dire che cambiando http in
https non funzionano restituendo un errore diverso da quello che ha
originato il thread, infatti con https l'errore diventa "Definizione non
corretta dell'elemento di livello radice nello schema" mentre prima era
"Accesso Negato...risorsa..."

> Tu punti a w3 per alcune cose (e w3 ti rompe 'o kaz...) e all'agenzia delle entrate per altre
> NON C'E' NESSUN LEGAME TRA LE 2 COSE, infatti hai 2 url diversi.
>

Si, su questo sono d'accordo e lo capisco ma perché con le chiamate http
c'è un errore di "Accesso negato" e con https (che dovrebbe funzionare
meglio visto il problema sollevato da w3.org) l'errore cambia in
"definizione non corretta..."?
In teoria cambiano solo le chiamate allo stesso url.

Comunque devo dire che w3.org è molto collaborativa, ancora oggi ho
ricevuto una email di w3.org che mi chiede se con le ultime eccezioni al
reindirizzamento a tutti i loro files .xsd e .dtd il problema è stato
risolto.
Mi hanno chiesto persino il mio indirizzo ip per verificare le chiamate
che vengono indirizzate ai loro server proprio dal mio indirizzo per
verificare cosa succede e cercare una soluzione.

Grazie.

[Alberto Salvati]

> In una risposta che mi hanno inviato loro stessi (w3.org) consigliano di
> modificare i files .xsd affinché lavorino con copie locali dei loro files.

Non pretendo di insegnare nulla a w3, sia chiaro, ma io non lo farei...

> Mi accorgo che mi esprimo da cani: intendevo dire che cambiando http in
> https non funzionano restituendo un errore diverso da quello che ha
> originato il thread, infatti con https l'errore diventa "Definizione non
> corretta dell'elemento di livello radice nello schema" mentre prima era
> "Accesso Negato...risorsa..."

In troppi casi i messaggi di errore sono fuorvianti.
Magari "dietro le quinte" fa una serie di controlli e quel messaggio viene fuori per qualche condizione non gestita al meglio.
Microsoft, ad esempio, è bravissima nel buttare fuori messaggi di errore che non c'entrano nulla con il problema vero...

In teoria cambiano solo le chiamate allo stesso url.

E chi se ne fotte di una teoria che viene smentita dai fatti?

Poi, si, è lo stesso URL ma cambia il protocollo.

> Comunque devo dire che w3.org è molto collaborativa

Ci siamo talmente abituati a coloro che latitano da farci sorprendere da chi lavora come si deve....

A.

[Luigis]

Il 07/09/2022 09:53, Alberto Salvati ha scritto:
>
>> In una risposta che mi hanno inviato loro stessi (w3.org) consigliano di
>> modificare i files .xsd affinché lavorino con copie locali dei loro files.
>
> Non pretendo di insegnare nulla a w3, sia chiaro, ma io non lo farei...

Non vorrei farlo neanche io, infatti sto collaborando con w3.org
sperando di riuscire a trovare la soluzione e tornare ai file originali
ufficiali.

Grazie.