---------
pre-generate the XSD file using a 3rd party tool such as XMLSPY and just output that file using text processing (strtofile type of thing) when I create the XML file.
-------------

I'm curious, why do you need to output it at all every time you generate the XML file?

Do you have some unusual requirement for an in-line schema rather than a reference to a schema? ordinarily they're not included in the document on every "go", and they don't need to be posted along with the data. There are a couple of possible reasons, I'm just wondering about yours.

As a second comment, sure, go ahead and use XML Spy to generate your initial schema, it's a great way to get started. But it is not optimal.

Remember that a generated schema is no better in XML than it would be if you were using a Table Wizard in FoxPro <g>.

Start with the XSD you get from XML Spy and then realize it's just the generic best the tool can do. Do you have rules and triggers, do you have data validation for your data? Of course you do -- and XML Spy will do the best it can to guess based on the sample that you give it, but you can do a lot better starting from that basis.

XSD is *great*. It can be frustrating at the beginning but it can express whatever you need it to express, including specifying enums, uniqueness, references, and other requirements.

Assuming you really have a requirement to publish your XSD, you want it to express your data schema as well as possible, not just be XML Spy's guess, right?

Because theoretically the application or individuals on the other end of your transmission are trying to discover something about your data from the XSD (otherwise why would they bother having this requirement at all).

So... a little more information please... <s>...

... Is your XSD static?

If it is static, once again, I'm interested in why you would need to send it along with each document instance. Whether you are sending it with each instance or just publishing it, you will start from a base XSD generated by some tool and then optimize it to be a more accurate portrayal of your data. I promise to help <g>.

If not, you will start from a base document generated from XML Spy or someplace, you will make it more optimal, and then at runtime you will *still* load it into the DOM and tinker a bit (for example, load in a dynamic set of enumerated values for a particular attribute, or add annotation in different languages).

Yes I read the rest of the thread and I know that you think there are performance issues with manipulation via -- but XSDs are not exactly gigantic documents <s>. Let's get real here <g>.

You can do it through SAX too if you want. You'd either run your actual data document through the SAX handler, sort of a custom version of what XML Spy is doing, or you'd run a base XSD document through the SAX handler, and make a couple of tinkering changes to that.

The learning curve to write the SAX handler will be overkill in your case, considering that you are already using the DOM to build your data and will be comfortable with that syntax, and once again performance isn't an issue especially if you already plan to use the DOM to build the data tree.

>L<