[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)
I really believe, at the moment, that my ultimate database would have XML based tables and allow relational (possibly even SQL) queries along with an XQL/XML-QL structured queries. Normalization could take several forms and allow non-normalized or threshold normalized forms. Of course the SQL-XML view on things would not have full XML structuring capabilities, it would provide a great bridge and in fact solve quite a few annoying problems that RDBMS's and OODBMS's haven't really solved satisfactorily: schema migration and flexible schema's. I have some ideas, but I'm going through some references to see what I'm missing right now. sdw Paul Prescod wrote: > "Borden, Jonathan" wrote: > > > > > 3. Therefore we should pretend that relational databases are really DOM > > > trees. > > > > no. if the data is tabular then use a recordset. in the specific cases when > > 1) we are storing data which is naturally hierarchical. 2) when the data > > needs to interface with systems which for other reasons employ DOM > > interfaces > > Okay. We can probably all agree with this. If you have software that is > expecting a DOM and you need to connect it to data that is not XML, you > need to build a DOM interface. This is a different point of view from > those who say: "let's build new client software using only the DOM served > by data with only a DOM interface. The fact that the DOM is standardized > will just make all of my interoperability problems go away." No way. If > your client software and your server software had an impedence mismatch, > slapping a DOM interface on both sides makes it *worse* not better. > > > e.g. my XSL processor us built on a DOM interface and I wish to > > query the database using XQL (which happens to be built into my XSL > > processor in this example), it is more convenient to interface to the data > > using DOM interfaces than it is using recordsets (i.e. tabular data). > > It's more convenient but it's probably going to run as slow as hell. > Nobody implements SQL or OQL on top of an industry-standard interface. > They put it right in the core engine of their database. > > > Arguably, when using an ODBMS this example would be more straightforward > > (but you picked RDBMS). The problem is that there is no standard, language > > independent interface onto ODBMS's. > > ********** Yes there is! ************* > > It isn't as widely hyped as XML/DOM. I haven't written a book about it > (and hardly has anyone else). But the standards *do* exist. Check > http://www.odmg.org. There are well defined APIs, bindings in a few > languages, a solid object model and a query language. It's all in there. > > My fear it that these technologies will get lost in the XML hype. > > > The DOM, while not the perfect interface > > *is* standard, and this is the big utility. > > The DOM is a standard for accessing XML, HTML and CSS information. It > isn't for modelling arbitrary business objects. It wasn't designed for > that and it isn't good at that. > > > For example, I get to say (using 'extended DOM'): > > > > NodeList anotherSet = airplanes.selectNodes("airplane[@color='red' and > > .//screw/thread/@pitch = 64]"); > > > > to select all red airplanes with screws having a pitch=64... > > The DOM is doing essentially nothing here. This imaginery XML query > language is doing all of the work. But even the XML query language is > going to make solving your problem harder than OQL would. For instance OQL > can be statically type checked. XQL cannot, in general, for many subtle > reasons. OQL can handle mathematical range constraints. OQL has a concept > of a "stored query" that allows some level of abstraction. OQL has "local > variables" also for abstraction. > > I don't completely follow your examples: > > > XMOP for example (http://jabr.ne.mediaone.net/documents/xmop.htm) is a way > > to serialize arbitrary COM objects using their typeinfo metadata. XMOP is a > > layer that can persist objects into either a) a stream (serialization) b) > > direct-to-DOM. When I attempted to design a direct-to-Recordset persistence > > interface on XMOP I found that I had to essentially develop a > > DOM<->Relational mapping. This is because arbitrary objects can be modelled > > in a hierarchical fashion (e.g. serialized to XML). > > This seems like a serialization problem. We all agree that XML is great > for serialization. If your only goal was to get the data into a "database > of some kind" then an OO database would have been easier than an XML > database. > > > In another example, using the medical imaging DICOM protocol (a complex > > property based protocol) I have developed a mapping to the Microsoft > > PropertySet format (used with Index Server). This mapping is not clean (at > > all given the inability to represent certain DICOM structures as > > PROPVARIANTs). This causes similar problems in mapping the protocol to a > > relational database (the workaround is to use binary data). Using XML and > > the DOM was a piece of cake to solve this difficult problem. > > I'm not at all clear on how the DOM solved this impedence mismatch. > > -- > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > > "Remember, Ginger Rogers did everything that Fred Astaire did, > but she did it backwards and in high heels." > --Faith Whittlesey > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@i... the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@i... the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@i...) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|