[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved

When I try this command:
xsd /c /e:Transaction /l:cpp LargeSchema.xsd

I get a number of "schema validation: warnings and "element is not declared"
warnings. Finally, processing stops with a "datatype xxx is missing" error.

LargeSchema.xsd opens and validates in XMLSpy. Is it possible the schema is
too complex for xsd.exe to handle? Are there any alternatives to xsd.exe?

Thanks for any suggestions.

"Schemer" <nowhere (AT) man (DOT) com> wrote

Most likely, there is another schema involved, and include schema, that has
to be accounted for in the build.

If the XSD is valid, then you should be able to pull all schemas involved
into a project by using VS Project Add Existing Item, which will resolve or
expose all problems with the XML schema.

The one area that you can look it is the <namespace> tag, which indicates
what namespace the XML is in and is using.

XML.xsd that is not in the same <namespace> as the parent XSD can cause a
missing element condition, along with the <include> XSD not being found
period.

Here is the output in VisStudio 2005:

1>Error: There was an error processing
'..\..\..\WorkMIMB\WFS-T\schema\wfs\1.1.0\wfs.xsd'.
1> - Error generating code for DataSet ''.
1> - Unable to convert input xml file content to a DataSet. Type
'http://www.opengis.net/ows:ServiceType' is not declared, or is not a simple
type.
1> - Type 'http://www.opengis.net/ows:ServiceType' is not declared, or is
not a simple type.

wfs.xsd contains, before ows:ServiceType is referred to, this line:
<xsd:import namespace="http://www.opengis.net/ows"
schemaLocation="../../ows/1.0.0/owsAll.xsd"/>
owsAll.xsd contains
<include schemaLocation="owsGetCapabilities.xsd"/>
which contains
<simpleType name="ServiceType">

Here is a snippet of wfs.xsd:
<xsd:import namespace="http://www.opengis.net/ows"
schemaLocation="../../ows/1.0.0/owsAll.xsd"/>
<!-- ================================================== ================ -->
<!-- = BASE REQUEST TYPE = -->
<!-- ================================================== ================ -->
<xsd:complexType name="BaseRequestType" abstract="true">


It appears the error is occurring with BaseRequestType, yet ows:ServiceType
should be recognized at that point.

Thanks for any insight into what is going wrong...

(As I mentioned, XMLSpy says this is valid, as does LiquidXML.)

"Schemer" <nowhere (AT) man (DOT) com> wrote



I wish I could help you. I am in my own Hell with XSD(s) from a third party
vendor. I am kind of in the same boat you are in, for a week now. I
don't have problems with the XSD in making a dataset class or serialized
XML object class with the XSD.exe utility. My problem is deriving an ADO.Net
dataset with an .XSD., which is basically the same problem you're having.

Let's stay in touch here, because if I get a resolution from the 3rd party
vendor, I'll post it. I hope you will do the same.

"Schemer" <nowhere (AT) man (DOT) com> wrote


If you're out there, you might want to take a look at this. It got me around
my problem. I just build the XML myself, based on the XML files that were
provided to me and their XSD(s).

http://support.softartisans.com/kbview_675.aspx

The download code for *aaron1.xml* allowed me to just build the XML(s) on
the fly the way I needed them. My next task will be to use a MemoryStream
and not write out any files.

"Mr. Arnold" <MR. Arnold (AT) Arnold (DOT) com> wrote

Thanks for the information. I'll probably end up using XMLTextWriter.
I am still hoping to somehow generate classes to encapsulate the complexity
of the schema, and still don't have any more information on why xsd.exe
fails when other tools accept the schema as valid...

"Schemer" <nowhere (AT) man (DOT) com> wrote

If you are able to generate classes *not* a class based on a dataset, then
you'll find that is a nightmare in itself, because a class only represents a
single root element and all of its sub elements. You generate the XML
individually class by class, and then you have to come up with some way to
string it altogether into one XML. Even using a dataset too, you have to get
the XML into a acceptable format that can be used.

If this is some 3rd party vendor's schema, then you need to jump on
someone's a$$, like I have done and make them produce the classes which is
what I did today. The came back telling the XML's must be based of the
schemas or XML provided. So, I put it to them. If you want it that way, then
you come-up with the classes need and demonstrate it in a project and give
it to me, because I am tired of dealing with it and the deadline is coming
up fast.