Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Opinions requested - more detail on what my thinking is.
 What is AFAIK? Maybe I've been confused by ODBMS products/sells documentation. At least three of them that I have looked at (Object Design, Ardent and Poet) seem to have fairly extensive XML API's as well as other tools that support xml storage in their databases. For example, poet supplies a check-in/check-out utility that is used as a version control system for content management of the xml structure stored directly into the DB. They also supply a browser utility that directly accesses the DB, giving an xml tree navigation, and display - I assume they are using something like microsoft's xml parser that renders to html and displays it. I assume that they are providing a set of java classes that model xml which is then stored directly in the DB (feed it an xlm file it stores an xlm object graph representing the document). I assume upon retrieval it simply streams (maybe as simple as toString())it's xml representation to the xml consumer who parses/renders it per dtd or whatever - no conversion processing is needed in the path until the consumer, keeping speed optimal, (pushing expensive parsing work to the client, relieving a busy server with time to dish up more). verses storing some java non-xml object in the database, you then retrieve the object from the database and wrap the information of the object into xml - and then ship it to some xml consumer, who then parses/renders it back into the non-xml objects form. It also seems to me that if the objects that you are storing are not xlm objects, you have lost the concept of Context Management or at least made it more complex to implement. I think this is where "betting the bank" comes in. To architect the system the second way would be to code a class per possible unique xlm element. You would then need to write classes to pull these "atomic" elements together etc. Upon retrieval you would then create the xlm for transport. This would isolate the DB storage and the client from xml because it would be your own animal, giving you extensibility via normal java class programming. To architect with xlm from the bottom up puts XML Content Management at the very root of the design. You are dependant upon the xlm protocol (not your own custom objects) to give you extensibility. Custom tags, meta-data, naming, versioning, whatever else xlm gives you, must be versatile enough to emulate the java class hierarchies of complex inheritance and aggregation graphs (as used in the option above). This allows for the same authoring tools used to develop content, to also develop navigation and other parameters that will be utilized at run time by the consumer of the xlm. I'm assuming the big buy here is code will only need to be written for the authoring tool, and the xlm consumer. All delivery from the db to the client (even via complex n-tier systems) would require very little, or no coding by us. Client code would parse out the displayable portions to html and display it. An applet would obtain the custom tags, meta-data etc. to make runtime decisions on what to do, based on things that could happen as the user interacts with the page. Our need: Author, name, store, revision, reuse, retrieve - pieces of documents, that can then be combined with other documents, which can in turn be combined with others ... Documents are composed of text, video, audio, graphics ... All the goodies of style sheets etc. would be used. Custom xlm tags would not be published at this time - interoperability with the world is not the driving requirement - ease of transporting documentation + special controls from an n-tier DB system running our code to a thin client running our code is. Meta data and custom tags would be used for several reasons - for example; enhance search and selection algorithms for authoring, bury navigational control data/logic that could be used at run time to help select the next element to display, bury management hooks that would trigger widl rpc to other processes based on runtime states etc. I'm also assuming that an ODBMS could deliver up complex linked, deeply nested xlm documents faster than open/read/closing hundreds of possible files to assemble some document. Concurrent open file handles also present a problem ... Have I missed the boat on what the ODBMS companies with XML Content Management Systems have to offer me? Chad > -----Original Message----- > From: owner-xml-dev@i... [mailto:owner-xml-dev@i...]On Behalf Of > Jeffrey E. Sussna > Sent: Thursday, March 04, 1999 6:57 PM > To: 'Chad Adams'; xml-dev@i... > Subject: RE: Opinions requested > > > I will not comment on the advisability of using an ODBMS, because > 1) it's out of scope for this group, and 2) it's a highly > religious topic. However, I will comment on the question of > whether to store your data directly as XML, and confess that I > don't understand the question. XML is a great interchange > language; i.e., a way to move data between systems. Generally > speaking, however, each particular system has its own optimal > internal representation. In an RDBMS, for example, it's tables. > In a Java program it's objects, and so forth. There is not > (AFAIK) yet any such thing as an XDBMS (though you could consider > a file system of XML documements plus a web server to resolve > URL's to those documents as such a thing). Anyway, my approach > would be to store data in the most natural format for the given > storage technology, and define translations to and from XML to > move data between systems. > > Jeff > > -----Original Message----- > From: owner-xml-dev@i... [mailto:owner-xml-dev@i...]On Behalf Of > Chad Adams > Sent: Thursday, March 04, 1999 5:17 PM > To: xml-dev@i... > Subject: Opinions requested > > > Forgive me for the generic question, I'm to the point of betting > the bank on > XML, and I'm looking for a pat on the back, or a voice of warning.... > > We are starting from scratch on our next generation product, from > what I've > read and seen - xml seems to fit the bill (Content Management, mixed with > WIDL RPC functionality seems right up our alley). I'm looking > hard at ODBMS > systems and laying out the DB via xml (storing xlm directly). We have a > wealth of in-house Java and COM/DCOM experience, but none with > ODBMS or XML. > > Do I understand it correctly that I at an item level, I can: > 1. name it (URI)? > a. possible supply some security to it? > 2. revision it? > 3. meta-data it? > a. can meta-data have meta-data? > > Would I be foolish to base my whole object system storage on xml, or on > ODBMS for that matter? Are they cooked, are they ready for real > world apps? > > Once again, I'm sorry for the generic question, I have read the FAQ's, the > ODBMS webpages, several books etc. I'm looking for the advice of those in > the trenches - Is it safe to make XML the foundation of my new product? > > Should I grab a shovel, and jump in the trenches with you, or is > this a deep > dark hole? > > > Thanks in advance, for all who might reply. > > > Chad Adams > Payback Training Systems > Email: cadams@c... > Phone: 435-654-6304 > fax: 435-654-1482 > > > > 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...) > > Chad Adams Payback Training Systems Email: cadams@c... Phone: 435-654-6304 fax: 435-654-1482 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
|
|||||||||
