>
>Hi Antonio el al,
>
>Thank you very much and everyone else for your input and the code. Excellent learning for me.
>
>But as far as my question, last night (after I already turned off my computer), I realized that I can do what I need in a very simple way. You see I know before hand what structure this or that cursor should have. When hard coding I use the syntax:
>

>create cursor MyCursor1 (field1 c(10), field2 n(12,2), field3 i)
>

>and so on. But I wanted to have the structure of these cursors outside of the code so that I can change it, if necessary, without changing the program. So the approach I though is as follows:
>

>*** text file MyCursors.txt
><Cursor1Name>field1 c(10), field2 n(12,2), field3 i</Cursor1Name>
><Cursor2Name>field1 c(40), field2 n(1,2), field3 i</Cursor21Name>
>

>So, at run-time, I can read this .txt (or other extension) file using filetostr(). And, then using STREXTRACT() get the structure of any cursor. It will be a very small Function. Then use the extracted line of the Structure in the CREATE CURSOR command.
>
>Again, thank you for your help!

In that case, I think that adding an XML layer introduces an unnecessary burden to the processing of the cursors. You'll process the definitions as a sequence of delimited strings, directly parsed by VFP string functions, not like an XML document, so no need to encode them in an XML document. For instance,

Cursor1Name:field1 c(10), field2 n(12,2), field3 i:
Cursor2Name:field1 c(40), field2 n(1,2), field3 i:

would be simpler and would do. I assumed a different scenario for your requirements because, since you've been digging around the consumption of Web Services, you might be getting the data structure downstream...

Anyway, I learned a few things of my own, specially some boundaries that must be respected when using XSD schemes and VFP native XMLTOCURSOR(): just one schema per document, and no local typed elements allowed.