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

I follow the same "rule" - one schema per document.