[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SV: Caught napping!
Hi Linda Welcome back. > schemas out there these days, they are often blatantly > influenced by an > underlying relational mentality. This is not a bad thing if your My experience (both RDBMS and XML DB) is that in the XML world, we all forgot about the datamodelling aspect. Stuff that the SQL crowd has been doing for decades, and learned to love and live with (as well as argue about, even mathematically), we just simply plain forgot. I guess that some of this is due to the fact, that XML grew out of the SGML world, a very document oriented world ? (Hey, the W3C XQuery group had forgotten everything about adding features for updating XML structures untill I talked with Jonathan Robie about it, since they worked fully from a "Querying documents" viewpoint...) Now we have XML, and allmost all the people I've met, are looking at using XML for data, and not documents. (Allthough one guy I know, told me: "We've been using SGML for decades for our technical documentation. It is great. It solves all our problems with _structured documents_. But now we're looking at XML to solve this, since the tools are cheaper, and the new kids thinks that SGML is old and dusty, whereas they love XML. But it is the same issue we're solving, structured documentation. Anyway, this guy had a punchline too, "We dont care about whether it is SGML, XML or SQL underlying the system, we just want structured documentation.") We need to realize, that all the SQL guys, have gotten used to nice helpfull features in the RDBMS, such as triggers, rules, joins, views, batchupdates, import/export tools, high performance, stored procedures etc., that makes life so much easier for you, when you're working with data. Remember that the MS in RDBMS stands for "Management System". Back to the datamodelling issue: I can easily design a relational schema, and I can even validate it, using mathematical formulaes and algortihms. This is great. I can optimize the data structures, so no matter what new needs my clients will make up, I can easily facilitate this, since I didnt get bogged down in a document structure. And I can rebuild any structure from my data (if I model them correctly.) With XML, I can make up a schema/DTD, but unfortunately I haven't got any ways to validate this schema. (Hey, where is the first really great book on XML Data/Document modelling?) We need to develop a process for doing XML datamodelling, so that it can be become a validated science and not just magical art. Then they even might begin to teach this methodology at the universities, just as they teach relational algebra and modelling. > around, would anything change? Referential integrity, for example, > between such mundane objects as customers and purchase orders might be > accomodated by treating the customer and his list of POs as a single > doc. Or, if the implementation is efficient enough in terms of data > footprint, by replicating customer data on each PO. Ouch!!!!! A fact about XML structures today, is that they promote data redundancy. And unfortunately, storing the customer together with all PO's will not guarantee RI as I see it. How do you then ensure, with a customer with 100 PO's, that when you change the phone no. of the customer, it is guaranteed to be updated on all 100 PO's ? I can agree that on a very statical web-site (maybe a bookstore?), you could store all the data as XML documents, and put all the info about a book into each XML document. But then again, what would be the benefits of this ? What we need is XML interfaces to the systems (web.services), and then the ability to quickly generate XML on the fly for transmission / multi device rendering using XSLT. > satisfactory and a real pain to maintain.) The ability to persist and > manage XML "natively" may now give us the choice. The analogy with Which is what I'd still like to see some real life industrial strenght examples of, that are not just XML "stores", but real XML DBMS, I mean XML Database Management Systems, with all the nice bells and whistles that the SQL crowd has gotten used to, joins, views, triggers (insert, update, delete etc.), rules, stored procedurs and high performance. And I would very much like to see a XML DBMS, supporting the W3C standard; W3C XQuery (it is a great effort and it has joins and views; definately needed, and W3C Schema for _real_ data modelling.) And I guess that when the XML really picks up speed, we will see the big ones, (IBM, Oracle, MS) add W3C XQuery and perhaps W3C Schema capabilites to their existing database systems, making it very easy to work with XML data/documents on the storage level. But all this will not solve the central issue: XML Data/Document modelling theory. This mail got a bit long, but I think that we need to addres the central issue to XML, the modelling theory. The "Native/not native XML" flame, reminds me a bit about the Mac/PC flames of yesteryear. How data is stored doesnt matter, it is how they are accessed, managed and modelled. All the best Jens Jakob
|
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
|