Java: проверка в автономном режиме XML с использованием локального XSD и SchemaFactory - PullRequest
1 голос
/ 06 марта 2020

В настоящее время я проверяю локальный XML файл с локальным XSD-файлом, используя этот метод:

    private boolean validate(File xmlFile) {
        SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
        try {
            Schema schema = schemaFactory.newSchema(new File(getResource("program_script.xsd")));

            Validator validator = schema.newValidator();
            validator.validate(new StreamSource(xmlFile));
            return true;
        } catch (SAXException | IOException e) {
            e.printStackTrace();
            return false;
        }
    }

Проблема в том, что он работает только онлайн. Запуск его в автономном режиме приводит к следующей трассировке стека:

org.xml.sax.SAXParseException; systemId: file:/C:/dev/repos/git/XmlApplication/target/classes/resources/program_script.xsd; lineNumber: 425; columnNumber: 63; src-resolve: Cannot resolve the name 'ds:Signature' to an 'element declaration' component.
    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
    at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4154)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:4137)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalDecl(XSDHandler.java:1684)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.traverseLocal(XSDElementTraverser.java:170)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLocalElements(XSDHandler.java:3610)
    at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:638)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:610)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:569)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:535)
    at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:254)
    at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638)
    at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:654)
    at br.com.services.GenerateXMLWriteService.validate(GenerateXMLWriteService.java:142)
    at br.com.services.GenerateXMLWriteService.createJaxbXml(GenerateXMLWriteService.java:128)
    at br.com.services.GenerateXMLWriteService.generateJabxml(GenerateXMLWriteService.java:86)
    at br.com.services.GenerateXMLWriteService.access$3(GenerateXMLWriteService.java:76)
    at br.com.services.GenerateXMLWriteService$1.call(GenerateXMLWriteService.java:68)
    at br.com.services.GenerateXMLWriteService$1.call(GenerateXMLWriteService.java:1)
    at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at javafx.concurrent.Service.lambda$null$493(Service.java:725)
    at java.security.AccessController.doPrivileged(Native Method)
    at javafx.concurrent.Service.lambda$executeTask$494(Service.java:724)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Стек трассировки указывает на schemaFactory.newSchema(new File(getResource(SCHEMA_FILE))) в качестве строки, вызывающей проблему. Как я могу решить это? Есть ли способ использовать SchemaFactory для автономной проверки XML, или он должен быть подключен к сети для доступа к схеме XML для SchemaFactory.newInstance? Могу ли я поместить эту схему в проект? Если да, то как и какой метод мне использовать для доступа к нему?

Это файл .XSD:

<?xml version="1.0" encoding="utf-8"?>

<xs:schema version="2.1" 
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns="urn:com:ssn:pc:program:schema:v2.1:SSN_COSEM_Program.xsd"
        targetNamespace="urn:com:ssn:pc:program:schema:v2.1:SSN_COSEM_Program.xsd"
        elementFormDefault="qualified">

    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd" />

    <xs:annotation>
        <xs:documentation>Version 2.1</xs:documentation>
        <xs:appinfo>
           Update history
            11/07/2018: Branched from XSD v.2.2; removed most of the new features added in v.2.2 comparing to 2.0 while preserving overall 2.2 format
            and the following new features:
            ValidFromDate root element attribute, MeteringService element in FileInfo, NicBasedValidation operaton type, optional use of CompatibilityScript section.
        </xs:appinfo>
    </xs:annotation>

    <xs:simpleType name="NonEmptyStringType">
        <xs:restriction base="xs:string">
            <xs:minLength value="1" />
        </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="NonEmptyHexBinaryType">
        <xs:restriction base="xs:hexBinary">
            <xs:minLength value="1" />
        </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="ServiceType">
        <xs:annotation>
            <xs:appinfo>
                List of service type definitions for filtering out devices of incompatible types if any appear in the device list associated with
                the project or audit
            </xs:appinfo>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="Electricity"/>
            <xs:enumeration value="Gas"/>
            <xs:enumeration value="Water"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="FileInfoType">
        <xs:annotation>
            <xs:appinfo>
                Set of elements describing the script file.

                Vendor name and Model name are required as they are being used for displaying script file attributes in MPC.

                'Id' refers to the unique script ID defined by the vendor. It can be used to store unique program ID (a.k.a. tariff ID) that will be 
                displayed in MPC UI.

                'ProductID' is expected to be assigned and passed on to the vendors by SSN.

                'Description' field should be used to provide a list of static and dynamic parameter values that are being checked by the compatibility
                script section and which thus define meter hardware, firmware and program configuration that are compatible with the current program
                script. That list of compatible parameter values will be displayed in the Description field of the meter program in MPC UI for user reference.
            </xs:appinfo>
        </xs:annotation>
        <xs:all>
            <xs:element name="ProductId" type="xs:string" minOccurs="0" maxOccurs="1" />
            <xs:element name="MeteringService" type="ServiceType" minOccurs="1" maxOccurs="1" />
            <xs:element name="Vendor" type="NonEmptyStringType" minOccurs="1" maxOccurs="1" />
            <xs:element name="Model" type="NonEmptyStringType" minOccurs="1" maxOccurs="1" />
            <xs:element name="Id" type="NonEmptyStringType" minOccurs="1" maxOccurs="1" />
            <xs:element name="Description" type="xs:string" minOccurs="1" maxOccurs="1" />
            <xs:element name="SourceFile" type="xs:string" minOccurs="0" maxOccurs="1" />
        </xs:all>
    </xs:complexType>

    <xs:complexType name="RawAxdrDataType">
        <xs:annotation>
            <xs:appinfo>
                The data type of the value supplied for 'set' or 'action' requests or for data being matched with results of the 'get' request.
            </xs:appinfo>
        </xs:annotation>
        <xs:simpleContent>
            <xs:extension base="NonEmptyHexBinaryType">
                <xs:attribute name="Format" type="xs:string" use="required" fixed="raw" />
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>

    <xs:complexType name="MatchDataType" >
        <xs:annotation>
            <xs:appinfo>
                A structure for providing data to be used in a single match comparison with the data read from an object.

                Data element should contain A-XDR encoded data to be compared to that read from the the meter.

                ParameterName attribute can be used to identify the data read from meter's object during pre-program or pre-audit compatiblity checks or during program
                audit as a particular meter program parameter. (ParameterName examples: MODEL – for parameter holding meter model value, FW_VERSION – for meter firmware
                validation, etc.) Paramter name (if present) will be included in the message displayed in MPC UI when data read from the meter does not match that in
                the programming script (in its compatiblity or audit script sections).
            </xs:appinfo>
        </xs:annotation>
        <xs:choice>
            <xs:element name="Data" type="RawAxdrDataType" minOccurs="1" maxOccurs="1"/>
        </xs:choice>
        <xs:attribute name="ParameterName" type="xs:string" use="optional" />
    </xs:complexType>

    <xs:complexType name="ListDataType" >
        <xs:annotation>
            <xs:appinfo>
                A sequence of Data elements to be matched aginst the data read from the meter (for use in pre-audit and pre-program compatiblity checks
                        when script is compatible with more than one value of required meter's parameter - like several FW versions, or models, or programmable
                program settings of base programs when applying partial program). The values in the list should be supplied in the raw hex binary format 
                representing A-XDR data types: same type should be used for all values in the list. If an optional offset attribute is used, it should be
                same for all Data elements.

                ParameterName attribute can be used to identify the data read from meter's object during pre-program or pre-audit 
                compatibility checks or during program audit as a particular meter program parameter (see also appinfo for MatchDataType).
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Data" type="RawAxdrDataType" minOccurs="1" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="ParameterName" type="xs:string" use="optional" />
    </xs:complexType>

    <xs:complexType name="RangeDataType">
        <xs:annotation>
            <xs:appinfo>
                A sequence of elements defining a range of numeric data within which the data to be matched aginst the data read from the meter should fell
                (for use in pre-audit and pre-program compatiblity checks when script is compatible with more than one value of required meter's parameter,
                and the allowed values fell within a range of values - like FW versions from 2 to 4, etc.)
                The range can be open-ended (only min or only max value is specified for 'greater than or equal' or 'less than or equal' conditions).
                The min and max values must be of same numeric type in A-XDR defined format.

                ParameterName attribute can be used to identify the data read from meter's object during pre-program or pre-audit 
                compatibility checks or during program audit as a particular meter program parameter (see also appinfo for MatchDataType).
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="MinValue" type="RawAxdrDataType" minOccurs="0" maxOccurs="1" />
            <xs:element name="MaxValue" type="RawAxdrDataType" minOccurs="0" maxOccurs="1" />
        </xs:sequence>
        <xs:attribute name="ParameterName" type="xs:string" use="optional" />
    </xs:complexType>

    <xs:attributeGroup name="ObjectIdentificationParameters">
        <xs:annotation>
            <xs:appinfo>
                Parameters identifying COSEM object instance that is being acted upon by set, get, and action requests.
                LogicalName attribute is expected to use dot character '.' as a delimiter.
            </xs:appinfo>
        </xs:annotation>
        <xs:attribute name="ClassId" type="xs:unsignedInt" use="required" />
        <xs:attribute name="LogicalName" type="NonEmptyStringType" use="required" />
    </xs:attributeGroup>

    <xs:complexType name="SetRequestType">
        <xs:annotation>
            <xs:appinfo>
                Definition of the set request elements for performing writes to the COSEM objects.

                The Data element should contain A-XDR encoded hexBinary data to be written to the object's attribute.
            </xs:appinfo>
        </xs:annotation>
        <xs:choice>
            <xs:element name="Data" type="RawAxdrDataType" minOccurs="1" maxOccurs="1"/>
        </xs:choice>
        <xs:attributeGroup ref="ObjectIdentificationParameters" />
        <xs:attribute name="Attribute" type="xs:unsignedInt" use="required" />
    </xs:complexType>

    <xs:complexType name="ActionRequestType">
        <xs:annotation>
            <xs:appinfo>
                Definition of the the action request elements for performing method invocations on the COSEM objects.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="MethodInvocationParameters" type="RawAxdrDataType" minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
        <xs:attributeGroup ref="ObjectIdentificationParameters" />
        <xs:attribute name="Method" type="xs:unsignedInt"  use="required" />
    </xs:complexType>

    <xs:complexType name="GetRequestType">
        <xs:annotation>
            <xs:appinfo>
                Definition of the get request elements for performing reads from the COSEM objects.
            </xs:appinfo>
        </xs:annotation>
        <xs:attributeGroup ref="ObjectIdentificationParameters" />
        <xs:attribute name="Attribute" type="xs:unsignedInt" use="required" />
    </xs:complexType>

    <xs:group name="CosemDataValidationGroup">
       <xs:annotation>
            <xs:appinfo>
               This is a group consisting of a GET request element paired with a choice of elements supplying data for comparison with the data
               returned from that object - such as data for a single match comparison, a list of matching values, or a range or allowed values.

               Get-Request-Normal element's attributes contain refrences to the object and its attribute to be read.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
                <xs:element name="Get-Request-Normal" type="GetRequestType" minOccurs="1" maxOccurs="1" />
                <xs:choice>
                    <xs:element name="SingleMatch" type="MatchDataType" minOccurs="1" maxOccurs="1" />
                    <xs:element name="List" type="ListDataType" minOccurs="1" maxOccurs="1" />
                    <xs:element name="Range" type="RangeDataType" minOccurs="1" maxOccurs="1" />
                </xs:choice>
        </xs:sequence>
    </xs:group>

    <xs:simpleType name="ValidationScopeType">
        <xs:annotation>
            <xs:appinfo>
                List of scope definitions for meter compatiblity validation purposes; should only be used in the CompatiblityScript section of
                the DeviceScript
            </xs:appinfo>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="ALL_SCRIPTS" />
            <xs:enumeration value="PROGRAMMING_ONLY" />
            <xs:enumeration value="AUDITING_ONLY" />
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="CosemPduType">
        <xs:annotation>
            <xs:appinfo>
                COSEMPDU type definition for the elements containing set, get or action instructions.

                'Scope' attribute should only be used in the 'CompatibilityScript' section. Its purpose is to define the validation specified in the
                particular instruction as required either for both pre-programming and pre-auditing compatibility checks, or just for one of them.
                If no scope attribute is present, 'ALL_SCRIPTS' is assumed.
            </xs:appinfo>
        </xs:annotation>
        <xs:choice>
            <xs:element name="Set-Request-Normal" type="SetRequestType" minOccurs="1" maxOccurs="1" />
            <xs:element name="Action-Request-Normal" type="ActionRequestType" minOccurs="1" maxOccurs="1" />
            <xs:group ref="CosemDataValidationGroup" />
        </xs:choice>
        <xs:attribute name="Scope" type="ValidationScopeType" default="ALL_SCRIPTS" />
    </xs:complexType>

    <xs:complexType name="SessionDelayType">
        <xs:annotation>
            <xs:appinfo>
                An element instructing NIC to pause programming script execution while either maintaining the connection session or renewing it.
                LogOff denotes whether the communicaton session with the device should get terminated and then renewed after the delay.
                Seconds denotes the number of seconds the pause lasts.
            </xs:appinfo>
        </xs:annotation>
        <xs:attribute name="LogOff" type="xs:boolean" use="required" />
        <xs:attribute name="Seconds" type="xs:unsignedByte" use="required" />
    </xs:complexType>

    <xs:group name="NicDataValidationGroup">
        <xs:annotation>
            <xs:appinfo>
                This is a group consisting of a NIC parameter read command paired with an element containing data for comparison with the data 
                returned by the NIC read command.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element maxOccurs="1" minOccurs="1" name="GetConfigTag" />
            <xs:element maxOccurs="1" minOccurs="1" name="ExpectedData" type="NonEmptyStringType"/>
        </xs:sequence>
    </xs:group>

    <xs:complexType name="NicDataValidationType">
        <xs:annotation>
            <xs:appinfo>
                NicOperation type definition for the elements containing commands getting device-related information from the NIC the device is connected to 
                or registered with. Responses from such commands can be evaluated in matching operations during compatiblity check or configuration audits.
                Only GetConfigTag command is supported in this XSD version.

                NOTE: Reserved for Itron use or for Itron partners use when recommended by Itron. 

                'Scope' attribute should only be used in the 'CompatibilityScript' section. Its purpose is to define the validation specified in the particular
                instruction as required either for both pre-programming and pre-auditing compatibility checks, or just for one of them. If no scope attribute
                is present, 'ALL_SCRIPTS' is assumed.
            </xs:appinfo>
        </xs:annotation>
        <xs:group ref="NicDataValidationGroup" />
        <xs:attribute default="ALL_SCRIPTS" name="Scope" type="ValidationScopeType"/>
    </xs:complexType>

    <xs:complexType name="DlmsDeviceOpType">
        <xs:annotation>
            <xs:appinfo>
                Device operation type definition. Can be COSEMPDU or NIC based validation, or a Delay operation, which is a non-COSEM operation that 
                provides possibility to insert a pause between set/get/method invocation actions with or without logging off/on.

                Attribute 'Length' shows the total number of operations to be executed.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:choice minOccurs="1" maxOccurs="unbounded" >
                <xs:element name="COSEMPDU" type="CosemPduType" minOccurs="1" maxOccurs="1" />
                <xs:element name="NicBasedValidation" type="NicDataValidationType" maxOccurs="1" minOccurs="1" />
                <xs:element name="Delay" type="SessionDelayType" minOccurs="1" maxOccurs="1" />
            </xs:choice>
        </xs:sequence>
        <xs:attribute name="Length" type="xs:unsignedInt" use="required" />
    </xs:complexType>

    <xs:complexType name="DlmsCosemType">
        <xs:annotation>
            <xs:appinfo>
                A type defining a device script as an DLMS/COSEM script which consists of a sequence of operations performed on a device.
                It is a sequence of any device operations (DlmsDeviceOperations) for the purpose of device programming or just a sequence of only GET 
                requests for the purpose of program audit or program compatiblity checks.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="DlmsDeviceOperations" type="DlmsDeviceOpType" minOccurs="1" maxOccurs="1" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="DlmsCosemScriptType">
        <xs:annotation>
            <xs:appinfo>
                A type defining a parent of any DLMSCOSEM script type.
            </xs:appinfo>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="DLMSCOSEM" type="DlmsCosemType" minOccurs="1" maxOccurs="1" />
        </xs:sequence>
    </xs:complexType>

    <xs:attributeGroup name="ScriptHeader">
        <xs:annotation>
            <xs:appinfo>
                ProgramType describes the program script as full or partial meter program (default is "Full").

                Name is the script name.

                ActivationDate and ExpirationDate should be set accordingly if the script contains time sensitive information. Both activation and expiration
                dates affect only ability to execute the program script section, that is, the program can only be applied within the specified time frame.
                Audit script will still be executalbe outside that time frame (particular audit instructions might have their own actiation and expiration dates).
                Additionally, particular programming instructions might also have their own activation and expiration dates.

                It is highly recommended to explicity specify desired time zone in the activation and expiration dates. If none is specified, the time zone of
                the host on which MPC is running will be assumed (all W3 standard date and time related data types used by XML define time zone offset property
                as optional).

                MaxPduSize shows max size in bytes of the PDU commands (Set and Action requests) accepted by the meter model for which the program script is
                intended (it will be used by MPC to break the data being sent to the meter into the blocks according to the max supported PDU size when the data
                size in the Set-Request-Normal and Action-Request-Normal commands is greater than the max supported size).
            </xs:appinfo>
        </xs:annotation>
        <xs:attribute name="ProgramType" use="optional" type="xs:string" default="Full" />
        <xs:attribute name="Name" use="optional" type="xs:string" />
        <xs:attribute name="DateCreated" use="optional" type="xs:dateTime" />
        <xs:attribute name="DateUpdated" use="optional" type="xs:dateTime" />
        <xs:attribute name="ExpirationDate" use="optional" type="xs:date" />
        <xs:attribute name="ValidFromDate" use="optional" type="xs:date" />
        <xs:attribute name="MaxPduSize" use="optional" type="xs:unsignedInt" />
    </xs:attributeGroup>

    <xs:complexType name="SSNCosemDeviceScriptType">
        <xs:annotation>
            <xs:appinfo>
                SSNCosemScriptType designates a set of scripts consisting of COSEM objects along with operations to be performed  on them (reads, writes, method
                invocations) designed to modify configuration of the target meter, or only consisting of GET requests necessary for validating (auditing) existing
                meter configuration or for performing pre-programming and pre-auditing compatibility checks of the meter paramters. 

                The ScriptFormat attribute designates the type/purpose of the script. 

                The Version attribute designates the script file format version (2.1 as of this specification; this number will change as the specification changes).
            </xs:appinfo>
        </xs:annotation>
        <xs:all>
            <xs:element name="FileInfo" type="FileInfoType" minOccurs="1" maxOccurs="1">
                <xs:annotation>
                    <xs:appinfo>
                        Section that identifies meter model (user readable string to be displayed in MPC UI, required), vendor name (required), script 
                        file source, program description (a list of meter parameters compatible with this program, required), product ID, and script ID
                        (required).
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
            <xs:element name="CompatibilityScript" type="DlmsCosemScriptType" minOccurs="0" maxOccurs="1">
                <xs:annotation>
                    <xs:appinfo>
                        Section that identifies static parameters and dynamic settings to be validated on the meter to ensure that the meter
                        and its current settings are compatible with the program or audit scripts to be executed.

                        It is expected that the CompatibilityScript will only use GET requests within its DlmsDeviceOperations sequence (since 
                        the compatiblity checks are not expected to alter meter state or configuration in any way).
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
            <xs:element name="ProgramScript" type="DlmsCosemScriptType" minOccurs="1" maxOccurs="1">
                <xs:annotation>
                    <xs:appinfo>
                        These are the meter programming instructions to be executed. All instructions shall be executed in the order in which they appear.

                        Note: Scope attribute is not applicable to operations defined in this script.
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
            <xs:element name="AuditScript" type="DlmsCosemScriptType" minOccurs="1" maxOccurs="1">
                <xs:annotation>
                    <xs:appinfo>
                        This script consists of a sequence of GET requests to be executed with an aim of program audit/verification. The program audit is 
                        a separate operation in MPC that is not performed in conjunction with executing the program script, but rather is the way to either 
                        identify the meters which need program change or those that already have desired program.

                        It is expected that the AuditScript will only use table reads within its C1219DeviceOperations sequence (since the program 
                        audit process is not expected to alter meter state or configuration in any way).

                        The puropose of this section as being separate from the program script is to allow for verification of any program configuration values 
                        and object data including those which might not be set directly by the SET requests contained in the ProgramScript section and are rather 
                        calculated as a result of the Action requests or set internally by the meter. It also allows to reduce the scope of auditing vs. writes 
                        contained in the ProgramScript section if there are writes to objects data in which is changing dynamically and which thus cannot serve 
                        as a base for auditing.

                        Note: Scope attribute is not applicable to operations defined in this script.
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
            <xs:element ref="ds:Signature" minOccurs="0" maxOccurs="1">
                <xs:annotation>
                    <xs:appinfo>
                        Optional element Signature should conform to W3 digital signature definition at http://www.w3.org/2000/09/xmldsig#.
                        It should include namespace attribute pointing to that definition: xmlns="http://www.w3.org/2000/09/xmldsig#" either at the Signature
                        element level or at the root SSNCosemDeviceScriptType element level (with Signature and its child elements referring to that namespase).
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>       
        </xs:all>
        <xs:attribute name="ScriptFormat" use="required" type="xs:string" fixed="SSNCosemProgramScript" />
        <xs:attribute name="Version" use="required" type="xs:string" fixed="2.1" />
        <xs:attributeGroup ref="ScriptHeader" />
    </xs:complexType>

    <xs:element name="DeviceScript" type="SSNCosemDeviceScriptType" />

</xs:schema>

ОБНОВЛЕНИЕ: Когда я удаляю элемент Signature из моего файла .XSD, проверка работает в автономном режиме без ошибок. Очевидно, он пытается получить доступ к «http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd» для проверки подписи.

Я попытался загрузить xmldsig-core-schema.xsd и поместить его в ту же папку, что и мой файл .XSD, изменив schemaLocation на xmldsig-core-schema.xsd, но это привело к той же ошибке.

...