Hello Steve,
> Hi, Scott. Lets see, if 80% of the world's data is unstructured in
> the SQL sense, and if most of that will be represented in XML by
> various editors and expected to be in XML by various search engines
> and applications, why wouldn't a "native" store be the most
> efficient method?
So you answer your own question ... because none of the current infrastructure is oriented towards this. Which means that all existing applications would have to now do constant conversions to access the information. And all current infrastructure, top to bottom, would need to be re-written to be optimized around XML ... and so then what happens when the next language comes along? Re-write again?
For some reason, many people think that XML is yet another "silver bullet" that is going to solve the worlds woes ... but it's just yet another step in a grand evolution that has no real end. XML will be replaced before long by the next formatting language ... or a compiled version ... or a compressed binary version ...
> Leaves the only layering required to the SQL boys who have 20
> legacy years to deal with.
Or the experience and knowledge of how to properly deal with these transiant Internet trends ... ;-)
> So why wouldn't XML replace .txt as the common denominator, and be
> stored that way? Not of course on the raw file system, but one step
> above that.
But this is not a real comparison! Today, the majority of the data that you are referring to is not in .txt (text) format! In the sentence above, you seem to say that Text format is a least common denominator ... but then also insinuate that it is the storage format. But, in reality, this isn't the case. It could be that .txt is a useful "common denominator", but most all applications store their data in formats that are optimized for the application ... IMHO, the way it should be.
Yes, it's technically feasible to re-write the entire world's data in XML ... but do you really think it makes sense? Just so that we can re-write it again in the future in the next popular format?
Also, I have to say that your comment on the "raw" file system is my exact point ... once you have given that point, then the whole story around XML has to be carefully examined ... use it where it makes sense ...
> So XML conversion, in-the-flow, makes sense, but why not store that
> as XML once converted and not re-incur conversion overhead the next
> time?
Ahhh ... you mean like caching ... like caching a web page? ;-)
Yes ... I do think that caching makes sense ...
> I totally agree on schema, and one, non-Microsoft (I almost said
> proprietary, but have a New Year's resolution to be nice to those
> poor guys) approach, is the combination of XML name spaces (xmlns)
> and RDF based inference engines. There will be a lot of schemas. No
> one can control that - just need to figure out how to "fix up"
> collisions. A brave new world.
Yep, I agree completely ... this comes down to the end user interface, and how people are presented with the "problem" that needs to be resolved ... and, IMHO, the various Internet "communities" which are created to assist with this "translation" of schemas ...
Scott C. Lemon |
