Cart
[Home] [By Thread] [By Date] [Recent Entries]
Nicolas LEHUEN wrote: > > I don't think a node-labeled tree (the XML model is a tree, more > restricted than a graph) structure can model all kind of data > easily and efficiently. There is a wealth of discussion on representing graphs in XML. Techniques include ID/IDREF, XLink/XPointer, RDF, TM etc, etc. The easy and efficient part depends on the implementation. > > So I believe there is a whole set of problems that will benefit > from XML databases (which are I believe based on the hierarchical > database model*, maybe Mike can confirm/infirm). The storage, > indexation and querying of a set of document-oriented data is a > good example. Similarly there is a lot of work on XML 'enabling' of relational databases. > > But XML databases isn't or (won't) be a revolution, blasting all > other storage models. We could even say that the XML database > model is just a come back of the hierarchical model that was > supposedly "killed" by the relational model back in the 80s. I > don't think XML databases are the "next thing". If we forget hype and terminology, there *is* real work being done on the XML Query Model and XML Query languages. One needs to distinguish between a query model and an internal representation. > ...AFAIK, the only ways a computer > can exchange data with a human being are serial, and I feel that > hierarchised text or speeches are the highest form of structured, > serialized data that we can understand. actually humans are not limited to serial data formats, e.g. images and voice which is interpreted by humans in a nonlinear, non serial fashion. > > C] In-memory data storage and manipulation using XML > > This last point on presentation is very important to me, as its > consequences finally made me to abandon any attempt of modeling > data as full-featured objects in the development of presentation > layers The work on types in schema languages would suggest otherwise. The DOM (L2) is limited to a small number of fixed types "element" "attribute" "text" .... When type support becomes a part of DOM Level ?.? the DOM does become a general 'object' model. It is not at all clear to me that representing everything in a DOM _saves_ memory. > > To save development time, deployment time, and memory (all thoses > classes modeling data come at a high price), we chose not to > model data as full-featured object, but simply as XML DOM > Documents. ... > > - it saves a lot of memory by removing application-specific > classes and replacing it with a small set of classes, the DOM. The statement that use of the DOM saves memory is against many common beliefs. (Indeed I try to use SAX as much as possible to avoid the DOM memory overhead.) Can you support these claims with some data? > > - it saves a lot of time and energy by the sheer flexibility of > XML. This is where XML wins hands down in my book. > > - contrary to Java class definitions, XML schemas (or schemata if > you prefer :) are quite difficult to read and write. And people will complain that XSLT is more difficult to read and write than Java, so? > > - compile-time checks are not performed. If you call > person.setFavoriteColour() on a Person instance, and the Person > class has not this method, you will get a compile-time error. > Using Java + DOM, a compiler cannot see an error when you try to > add the "favoriteColour" attribute or child element to a "person" > element. As we have developed a custom XML language compiled to > Java code, we feel that it is possible to make the compiler > schema aware, thus enabling compile-time checks when the schema > of the manipulated documents are known. correct on all accounts. in this sense these usages of XML have the same issues as all dynamically typed and/or interpreted systems ... and the same solutions :-) > > - "this is not pure object oriented programming !" I don't know > if it is the same out there, but here in France it matters to a > lot of people. that's too bad :-/ My current 5 seconds answer is that presentation > layers usually do not require a pure object oriented model for > data. It does not mean that the underlying framework of the layer > is not object-oriented, far from it ! i'd just say "but of course we use Java so it *is* object oriented"! > > - "yeah, but then how do I associate a behaviour to my data ?" In Texas you'd pull out a shotgun and blast at the general direction of the individual. In Boston we mumble some phrases about the "Semantic Web" ... "RDDL" ... wave our hands and then walk away :-)
|
