IMPORTANT:
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.

Newbie Setup Options · View
IPMM
Posted: Monday, June 3, 2019 5:47:49 PM
Rank: Newbie

Joined: 5/31/2019
Posts: 5
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):

C:\Users\username\Downloads\subschema.xsd

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)?
K101
Posted: Tuesday, June 4, 2019 8:35:39 AM
Rank: Advanced Member

Joined: 2/27/2009
Posts: 558
Do the imports and includes use an absolute path on your local filesystem, or relative ones? Were they relative, then XMLSpy would (should) resolve them relative to the base URL of the main schema.

Since it's online now, why not just provide the URL here?
IPMM
Posted: Thursday, June 6, 2019 1:27:20 AM
Rank: Newbie

Joined: 5/31/2019
Posts: 5
The schema is found at https://ledes.org/schema/IPMM/2016/L_Disclosure.xsd

<xs:import namespace="https://ledes.org/schema/common/2016" schemaLocation="L_AssociatedFile.xsd"/>
<xs:import namespace="https://ledes.org/schema/common/2016" schemaLocation="L_GenericTypes.xsd"/>
<xs:import namespace="https://ledes.org/schema/common/2016" schemaLocation="L_LegalEntity.xsd"/>
<xs:import namespace="https://ledes.org/schema/common/2016" schemaLocation="L_PersonName.xsd"/>
<xs:import namespace="https://ledes.org/schema/common/2016" schemaLocation="L_PersonalInfo.xsd"/>
<xs:include schemaLocation="L_Concept.xsd"/>
K101
Posted: Thursday, June 6, 2019 8:00:25 AM
Rank: Advanced Member

Joined: 2/27/2009
Posts: 558
Opening the schema directly from the URL in XMLSpy results in it trying to load the imported and included schemas relative to the base URL, and those schemas can't be found there.

For example, you would expect to be able to load the first imported schema from https://ledes.org/schema/IPMM/2016/L_AssociatedFile.xsd but it doesn't exist there.
IPMM
Posted: Tuesday, July 2, 2019 4:09:07 PM
Rank: Newbie

Joined: 5/31/2019
Posts: 5
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, https://ledes.org/schema/IPMM/2016. I was now able to access the various schemas by typing the respective URLs (e.g., https://ledes.org/schema/IPMM/2016/L_Concept.xsd and https://ledes.org/schema/IPMM/2016/L_AssociatedFile.xsd) into the browser.

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

Quote:
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="https://ledes.org/schema/IPMM/2016" schemaLocation="L_AssociatedFile.xsd"/>

to:

<xs:import namespace="https://ledes.org/schema/IPMM/2016" schemaLocation="https://ledes.org/schema/IPMM/2016/L_AssociatedFile.xsd"/>

(I would just make the change and see, but I do not have direct write access to LEDES directories.)
K101
Posted: Wednesday, July 3, 2019 8:45:52 AM
Rank: Advanced Member

Joined: 2/27/2009
Posts: 558
Your error messages make it look like you're downloading the schema file using a web browser, then that downloaded file (stored in a temp directory) is being opened by XMLSpy. That's not what you should do. Open the URL directly in XMLSpy (File / Open / Switch to URL).

Now XMLSpy can find those other schemas, though you're going to see some error messages about the namespaces which you'll have to address. Keep clicking "OK" on those messages and eventually XMLSpy will display your file in Schema View.
IPMM
Posted: Wednesday, July 3, 2019 8:45:36 PM
Rank: Newbie

Joined: 5/31/2019
Posts: 5
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, https://ledes.org/schema/IPMM/2016/L_UNECE_Imports.xsd 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 http://www.w3.org/2001/XMLSchema.xsd 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.
K101
Posted: Thursday, July 4, 2019 10:56:46 AM
Rank: Advanced Member

Joined: 2/27/2009
Posts: 558
The schema at the URL you previously provided still has imports rather than includes, so maybe update it there so others can have a look.
IPMM
Posted: Thursday, July 4, 2019 1:48:22 PM
Rank: Newbie

Joined: 5/31/2019
Posts: 5
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.
Users browsing this topic
guest

Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

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