>>If you ever have an XML source that is not already in the schema structure for XMLTOCURSOR() that is valid for it, you will need to transform that XML either using XSLT or with script, etc. The more XML and schemas that get created and exists in applications and services, the more transformations will be required, this is the state of likely future of XML usages. If you need to edit and debug XSLT, ActiveState (http://activestate.com) just released VisualXSLT for Visual Studio .NET. I know about it because I wrote the original specification for this VS.NET add-on and I also had XMLFund (my former employer) fund the project for ActiveState to build it because editing/debugging XSLT is so important for XML development regardless of the language used. VS.NET has a great XSD scheme editor and an XML editor that is extensible (you can add your own schemas for color coding and IntelliSense to match a schema when editing an XML document).
>
>Seems to be the things became slightly complicated before I was aware of that. I'll probably have to dig into this if the need arises. The whole matter came up because we had people who were designing the forms in Visio, and then the coders who were supposed to make them in VFP, and this is an attempt to automate the work. However, Visio is exporting too much stuff (complete stencil, help hints, bitmaps etc) and about 0.5% of the exported XML is what I need.
>
>Hmmm... does this extensibility mean we could stuff into (and extract from) an XML file a whole database, with foreign keys etc? With sufficiently inteligent parser, I figure we could do this, right?

Dragan,
PMFJI, but if you need a good XSLT book, I recommend Inside XSLT from New Riders. Here is the listing on Amazon: http://www.amazon.com/exec/obidos/ASIN/0735711364/newriderscom-20/102-3501929-0950509.

It helped me a lot with stuff.