Invoice schema does not import correctly
Forum topic: Submitted by MartinGK on Wed, 2016-04-13 14:18.
Hi folks
I'm working on PEPPOL/UBL for a customer, and have downloaded the 2.1 UBL schemas. The UBL-Invoice-2.1.xsd does not import correctly - there's a missing dependency for the http://www.w3.org/2000/09/xmldsig#:Signature element. That's in the UBL-xmldsig-core-schema-2.1.xsd file, which is not imported
I tried adding the UBL-SignatureAggregateComponents-2.1.xsd file as an import, as that in turn imports the xmldsig namespace, but that's still not working. A check of a couple of the other maindoc schemas suggests that this is a general problem.
Has anyone else hit this, or found a way round it?
Thanks
Martin GK
Remove DTD info in XML Schema
In 2013 I had a problem with signatures and .NET
I removed 6 lines from UBL-xmldsig-core-schema-2.1.xsd about DTD
Perhaps ask on the UBL Dev mail list
I'm not sure what to tell you, Martin. I think it is time to check a wider audience by posting your predicament to the UBL Dev mail list as documented at the top of the http://ubl.xml.org/forum page.
I'm guessing it is a conformance issue, based on the results of the tests I ran and reported to you on by running the UBL 2.1 schemas successfully through the Xerces, Saxon and Altova XML Validation processors without any error messages.
Perhaps by posting your experience on UBL-Dev someone there will recognize the issue.
. . . . . . Ken
Back to this again - same problem!
Hi Ken
Due to a loss of interest by the customer, I had to abandon this problem unsolved last time, but its come up again just last week, so I'm back on it again. I can confirm that using MS .NET 4.0, a simple load and compile of the UBM 2.1 invoice schema still produces the same exception - missing element http://www.w3.org/2000/09/xmldsig#:Signature. This is well before any validation against an actual XML file - this is just getting the schemas to load into a .NET SchemaSet object.
The code is as simple as:
XmlTextReader xtr = new XmlTextReader("UBL-Invoice-2.1.xsd");
XmlSchema aSchema = XmlSchema.Read(xtr, null);
XmlSchemaSet xmlSet = new XmlSchemaSet();
xmlSet.Add(aSchema);
The simple addition of the schema and the resulting handling of the imports and includes within the schema throws an exception for the missing element http://www.w3.org/2000/09/xmldsig#:Signature. This is using the current .NET 4.0.
Can anyone show any light on this, or suggest a way round?
Thank you
Martin Gordon-Kerr
Orion Consulting Ltd
http://www.orionltd.co.uk
Hi, To import the
Hi,
To import the UBL-Invoice-2.1.xsd ( and any other I think ) to generate classes from the XSD files ( with a tool like xsd2code++ ) just remove the DOCTYPE section in the UBL-xmldsig-core-schema-2.1.xsd file. ( I also moved all common files to the maindoc folder and removed the "../common" part from the relative import schemaLocation statements to get xsd2code++ going.
Manfred
Great advice!
Thanks Manfred, deleting the DOCTYPE finally resolved the validation errors!
Omer
No known dependency as described
Thank you, Martin, for your post. Although I am responding personally as a member of the community, it happens I am responsible for the XSD files generated from the business objects. I am unaware of any dependency issue and so I have not hit your issue. The UBL 2.1 invoice schema has been used globally for years without anyone else reporting such an issue.
As a sanity check just now I have successfully validated the UBL Invoice test instance in the UBL 2.1 distribution with the distributed XSD for the Invoice. As part of my pre-distribution tests I check with the Xerces, Saxon and Altova XML Validation processors, and as then they successfully pass today.
Can you cite where you believe the dependency is in the existing XSD files? Do you have an XML instance that triggers the dependency?
Posting here is fine for getting a community response, and I'm responding with my personal experience, but the best place to report this kind of concern with evidence is the UBL Comment List as this will trigger a formal response from the UBL Technical Committee.
I hope this helps!
. . . . . . Ken