this is not a Support Forum! Experienced users might answer from time to time questions posted here. If you need a professional and reliable answer, or if you want to report a bug, please contact Altova Support instead.

Profile: IPMM
User Name: IPMM
Forum Rank: Newbie
Real Name:
Gender: None Specified
Joined: Friday, May 31, 2019
Last Visit: Thursday, July 4, 2019 1:48:23 PM
Number of Posts: 5
[0.03% of all post / 0.01 posts per day]
Last 10 Posts
Topic: Newbie Setup
Posted: Thursday, July 4, 2019 1:48:22 PM
Even though I am the subcommittee chair, I do not have write access and must develop and test offline and then request that modified schemas be uploaded. Not my preference, but is what it is. I will get schemas with import-changed-to-include uploaded to the LEDES site and then post here.
Topic: Newbie Setup
Posted: Wednesday, July 3, 2019 8:45:36 PM
Many thanks. Yes, I was opening directly from the website as I assumed that would enable me to see the schemas from the same perspective of a user's xml processor. When I convert imports to includes most of the errors disappear. However, one remains.

Rather than create and maintain various codelists that are already maintained by UNECE, imports the UNECE codelists. That seemed to work previously. However, now XML Spy indicates that each element in L_UNECE_Imports.xsd "is already declared". It doesn't tell me in which schema document the element is already declared.

In a prior post, a user attempted to validate within XML Spy and received an "is already declared" error.

The responder indicated that the XML Spy "validator has this schema integrated into it, it is not possible to use it directly." While my situation is a little different (I am importing the ISO schema into one of the IPMM schemas, rather than trying to directly validate the ISO schema), might this be the cause of my errors?

A stackoverflow entry suggests that this means that the validator is seeing the schema twice - "either because it's got knowledge of the namespace built in (in which case you may not be able to make your validator use a modified schema for the namespace at all) or because of an error in the way you have put your schema together, or because of an error in the way the validator was invoked."

Another prior post suggests:
1) writing a CustomCatalog overriding or redirecting the links that are duplicate definitions
2) editing the coreCatalog to comment out the duplicates
3) editing your generated schema file to remove the duplicates.

I looked "upstream" at schemas that would consume this data and the following seems to be consistently used (which I assume references rather than declares):

<xs:element ref="lco:CountryCode"/>

Any thoughts would be appreciated. In the meantime, I will plug away. I do greatly appreciate the prior guidance.
Topic: Newbie Setup
Posted: Tuesday, July 2, 2019 4:09:07 PM
Apologies for the silence and for not realizing the lack of accessibility. I tried to access the child / common schemas and was unable. I went back to the person managing the system. The person was unable to resolve the lack of access to files in the common subdirectory and dumped the common schemas (along with the application-specific schemas) into the application-specific directory, I was now able to access the various schemas by typing the respective URLs (e.g., and into the browser.

I am still receiving the same message when I open the top-level schema (L_Disclosure.xsd):

SchemaView is unable to load following schema(s):

C:Users\[user name]\AppData\Local\Microsoft\Windows\INetCache\IE\PU8VPDAX\L_Concept.xsd
C:Users\[user name]\AppData\Local\Microsoft\Windows\INetCache\IE\PU8VPDAX\L_AssociatedFile.xsd

Based on your above guidance regarding relative vs. absolute location, can I avoid this error by including the entire path in the schemaLocation attribute? That is, can I change from

<xs:import namespace="" schemaLocation="L_AssociatedFile.xsd"/>


<xs:import namespace="" schemaLocation=""/>

(I would just make the change and see, but I do not have direct write access to LEDES directories.)
Topic: Newbie Setup
Posted: Thursday, June 6, 2019 1:27:20 AM
The schema is found at

<xs:import namespace="" schemaLocation="L_AssociatedFile.xsd"/>
<xs:import namespace="" schemaLocation="L_GenericTypes.xsd"/>
<xs:import namespace="" schemaLocation="L_LegalEntity.xsd"/>
<xs:import namespace="" schemaLocation="L_PersonName.xsd"/>
<xs:import namespace="" schemaLocation="L_PersonalInfo.xsd"/>
<xs:include schemaLocation="L_Concept.xsd"/>
Topic: Newbie Setup
Posted: Monday, June 3, 2019 5:47:49 PM
I am a non-technical person using XML Spy to develop and maintain an XSD-based standard. I have been using XML Spy for many years, but always in a very rudimentary fashion. That is, I have essentially used XML Spy as a fancy version of Notepad. After years of me agitating, the standards body has finally loaded the schemas directly online (they used to be accessible in a zip file). However, now when I attempt to open the online schema, I receive an XML Spy message stating,

SchemaView is unable to load following schema(s):


The parent schema loads with errors that reflect the above issue. I am unsure why SchemaView would be looking to my local downloads directory for the included and imported schemas. Should I be able to load the web-based schemas and have the parent schema load the included and imported schemas from their respective folders (equivalent to their respective namespaces). Or do I need to change my profile? Or should I be using the Project or other tools (that I have so far avoided)?

Use of the Altova User Forum(s) is governed by the Altova Terms of Use.