[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Question for updating existing XML file
MK> The XML spec gives some quite good clues as to what it was designed for. > "Its goal is to enable generic SGML to be served, received, and processed on > the Web in the way that is now possible with HTML." The design of XML gives > further clues: if they had wanted to design something that could be easily > updated in-situ, they wouldn't have used a grammar that can only be parsed > by starting from the beginning. The terminology also gives clues: a unit of > XML information is called a "document", not a "database". > OW> If all the parsing is done server-side, why does it matter? And if the XML Management System can make tons of changes in-situ without parsing or round tripping, then they have solved many of the bottleneck problems associated with XML being used for something more than the strict definition (whatever that is) of a document. NeoCore XMS does this. I would suggest that the "document" metaphor fits perfectly for a PurchaseOrder, CustomerProfile, Product Catalog and other like business objects. Although developers think in business objects all day long, at the end of the day most developers shred those rich objects into lots of little cubby holes, or just serialize them and stuff them into a big cubby hole; .and the richer (more complex) an object, the more relations required to store it in the SQL world. So am I storing documents? Yes. Am I using XML instead of a database? Yes I am merely suggesting there is a better way to store stuff, and that way also happens to be leaving the XML in its native format. > MK> I'm not talking about size, I'm talking about usage profile. > I don't think that using an XML document as a replacement for a > database is a particularly good idea >OW>Evolution would call it a replacement Revolution says there is a fundamentally better way, and that is not by using a bunch of XIncludes pointing to references of stuff, or creating documents that look perculiarly like RDBMS tables. Instead, build a physical representation of your business objects in well formed and semantically rich XML, and use those semantics and business objects as documents to break free of the storage chains that currently bind you. > MK> If I had meant relational databases, I would have said relational > databases. I have worked on many projects over the last 15 years that needed > much richer structures than relational databases offer. >OW>How did you solve this rich structures storage problem in the past, and what about XML precludes it from solving most if not all of these previous issues? > MK> I have no problem with the concept of XML databases, merely with the > concept of trying to use a single 50Mb document as if it were a database. OW> And now, I believe, we are at the crux of the problem. What or how people use documents is nobody elses concern (and can lead to significant competitive advantage :). That is why we have things like XSLT for translations, and Rosetta and ebXML, etc. defining all these interfaces, so you have a common language to talk with other systems; nobody says your have to use those XML structures internally. I am just saying, regardless of the schema of the XML (an industry standard interchange or internal structures) why not leave it in XML? Why always some other storage mechanism that either disassembles the XML or makes querying, updating and deleting in place nearly impossible? Maybe what we need are more verbs associated with XQuery than the implied SELECT; otherwise, every XML database vendor will do it (Insert, Update, Delete) differently, and in 10 years when everyone is using an XML database, you won't be able to switch from one XML database to another as easily as you can switch from Oracle to DB2 (assuming you don't use Oracles database extensions: stored procedures). MK> > (What I would really like to see is an XML database that gets rid of the > concept of "document" entirely. But we're a long way from that at the > moment. In all the systems I've seen, the choice of "what is a document" has > a profound effect on both the physical and logical design, and as a general > rule of thumb, many small documents works better than a few large ones.) OW> Maybe you should look at the Neocore XMS. It comes pretty close to what you are asking, by cheating the system. Every document in the system is <ND> and from there down the tree you have your own heterogeneous documents. Not necessarily the cleanest way to obecure the concept of a document, but this, combined with their capability to do insert, update and deletes both within and across documents in-situ (no roundtripping), the "size" of your document become irrelevant. Owen
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|