>Ah, but that's the rub! XML is not a "standard" here because the metadata schema for any factory we create is left to implementation. So we could both be using XML to store metadata but dissimilar structures makes our work incompatible without an adapter. The code I write to search or iterate my schema will likely need serious mods for use with your schema. If we use differeing versions of the MSXMLDOM (or whatever) then that's also problematic. So XML is better than comma-delimited ASCII in this respect, but it's not all that it could be.
Yeah, but that's true of VFP data in the same way. If the data structures don't match in cursors you also need an adapter. How many times have you had to write code to update meta data structures by checking for versions then doing copy out and reimport the data after having to make the required structure changes? This is a PITA. XML structures *generally* (though not always) can survive structure changes without even a schema change or continue to work in both forward and backward compatible manners.
Regardless of what kind of format you use you'll have version and interop issues to deal with - nature of the beast don't you think?
>>We have similar types of problems in VFP, though less severe. The table structures used by application metadata are left to implementation, but at least we can all agree that we'll all USE a table and LOCATE or SEEK to find the record we need, and we've got compile-on-the-fly, EVAL(), and functions to peek and poke property pairs from memo fields, etc. Moreover there are plenty of native tables in VFP, like BROWSER.DBF and .VCX/.SCX structures for example, that can be used for the 99% use case for any application metadata.
This is true, but here again you can do all that with .NET too. Sure you have VCX tables etc. but you have to know the structure of those tables, the formatting and plain inconsistent manner in which these formats were created. Yeah it works, you and I both have done plenty of work hacking this stuff in the past. And I hate it everytime I have to screw with it.
You have dynamic compilation in .NET (check out the CSharpCodeProvider (or VB, JScript) class, which allows for on the fly compilation and execution of code. Again it requires a one time class creation to set this up, but basically you can mimick the behavior of VFP plus a hell of a lot more.
Generating code? Everything in .NET is source code including forms so you can create program files and compile them on the fly and run them from memory or disk.
Funny, I was just playing with this stuff as we speak, because this was one of the major things I couldn't figure out how to do in .NET that is very important.
>The fact that VFP has a data engine, and that system metadata uses the same data engine, well that's just killer. SQL Server does this also, though for some reason any metadata access in SQL server seems to take hunderds of time longer to process. MSDE is, of course, no better. (I'm talking about the eternity of time it takes to access metadata "objects" in Enterprise Manager and Query analyzer). Were that not enough, string handling sucks in SQL/MSDE.
Yeah, VFP's string handling is the best bar none.
>I'm not saying you can't use XML for metadata, just that it's not as fast or handy as a .DBF, and that it looks to me like there might be some interesting correlation between metadata standards and the cohesiveness of developer communities.
I think that DataSets bridge that gap quite a bit making access to XML data a lot more like using a DBF in VFP.
