Cart
ASP Error: 70
Description: Permission denied
Source: Microsoft VBScript runtime error
|
[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?)
 What I am talking about is an interface to a database. The question is: should we use an interface such as ODBC, JDBC or a proprietary interface (each vendor has one), and/or the DOM. It has been suggested that when the database is to represent an XML repository of some sort, the DOM may be one appropriate interface onto this repository. In particular object database vendors such as ODI and Poet who are offering XML databases may choose to offer a DOM interface onto the database. Relational database vendors such as Oracle may also choose to offer DOM interfaces onto the database. It has been stated that this is a misguided approach, and that what is needed is object orientation. My response is that this is comparing apples to motorcycles. Modern systems are described at different levels and this is a useful way to organize this discussion which is in danger of becoming incoherent. Many current systems are described in terms of three broad tiers: a client tier, a middleware tier and a server/database tier. When these systems are designed, there exists a need to interface the tiers. When business rules exist on a middleware tier, and these rules are designed as a set of components or objects, these 'high level' objects which contain domain specific knowledge, have a need to communicate with the database tier. Frequently a set of data access objects is defined to facilitate interface with the database. We are talking about different levels. Not for a moment am I arguing with the need for business rules. The question is how these object rules should access the database. In modern middleware/transaction processing systems, the idea is to 'dumb down' the database and place the knowledge in the business rule layer (which is above the data access layer). Two tier systems mix the business rules with the data, this leads to inefficiency. A three tier system separates the business rules from the data. Yet low level API's such as ODBC or vendor specific API's tie the business rules to the particular database engine. With proper object orientation, and use of encapsulation, it is best to uncouple the business rules from the particular database. In other cases, a data access object layer is used to couple a 'high level' or scripting language to a low level binary wire protocol. For example, Microsoft offers ADO with its Recordset. I suggest that the DOM is no less capable of modelling data than a Recordset, where a Recordset is optimized to deliver tabular data, the DOM is optimized to deliver tree data. Perhaps you don't like the DOM and have a better tree API ... great! let's see it and then if everyone agrees that it is indeed better, it can be DOM 2. The concept of the 'object repository' or 'enterprise repository' includes the idea that code and data can be mixed together in a large bucket. These systems tend to have difficulties in high transaction volume applications. They have tended to be overly complex and hence overly expensive for this reason. At the same time the proper 3 tier web application (browser client, HTTP server/middleware, back-end database) has really taken off in the last couple of years (ask Dell :-) By maintaining a distinct business rules layer from the data access layer, the system can be more easily organized and more easily modified. This leads to higher reliability and lower cost. These are good things. So lets compare apples to apples. Which data access API do you wish to use? This API is specifically required to be used by business rules to access data stores. Paul Prescod wrote: > > Right. XML is a serialization. The DOM is an abstraction of a > serialization. Not an abstraction over your data. With objects, the data and code are tied together, we have the idea of a 'live' object and a persisted object. The idea of activating a persisted object means that the persistant object data (e.g. a file) is parsed to restore object state. A DOM object isn't so much an abstraction of a serialization as it is a live 'bucket' of XML data (it is a simple data access object). Business rules operate on data objects in the same way that a JavaScript program can use a DOM object to process some information. If your "problem" is > representing debit card bank accounts the proper abstraction over that is > "bank account" or "currency account". The *wrong* abstraction is "elements > and attributes." Comparing apples to apples, the DOM has elements and attributes, and a Recordset has rows and columns. Most bank accounts in the world today are well represented as rows and columns. There are times when the slightly more complex concept of elements and attributes has a better impedance match to the data being modelled than rows and columns. > > XML is very simple. "All the world's data" is very complex. That's why we > need XLink, RDF, HyTime and a bunch of other stuff. If your API to "your > data" is simply the DOM then you are temporarily hiding its complexity > behind a simple layer that can *NOT* express its "linkedness", its complex > class relationships, is geographical 2D-ness etc. I don't know your data. > I don't know what makes it complex but if your job is interesting it IS > complex and the DOM does not help you to manage that complexity. That's right, that's why *I* need to model my domain using *my* business rules. And assuming I don't want to code my own database, I need an API that allows me to store my stuff. > > > It is a big mistake to assume that XSL is only to be > used for 'styling for > > the Web or print'. DSSSL as we know is based upon or employs > Scheme. Scheme > > is a full fledged programming language, a dialect of LISP. XSL > does not have > > the Scheme counterpart to DSSSL, rather it is itself its own programming > > language (albeit currently simplistic). > > XSL is not a programming language according to the Turing/Church > definition. Perhaps not yet, but if I want to automate transforms, XSL or the transformation language subset 'XTL' is a leap in the right direction. A large part of computer programming consists of interfacing one API to another. I'm not saying that XSL helps with this at all but pointing out that transformations and impedance matching is an important task. If we have the ability to express transforms directly this greatly reduces the need to do traditional coding and bit twiddling. Jonathan Borden http://jabr.ne.mediaone.net 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
|
|||||||||
