Opinions requested - more detail on what my thinking is.

[Chad Adams]

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 at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
> Jeffrey E. Sussna
> Sent: Thursday, March 04, 1999 6:57 PM
> To: 'Chad Adams'; xml-dev at ic.ac.uk
> 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 at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
> Chad Adams
> Sent: Thursday, March 04, 1999 5:17 PM
> To: xml-dev at ic.ac.uk
> 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 at cascadecc.com
> Phone: 435-654-6304
> fax:   435-654-1482
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> 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 at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the
> following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> 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 at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the
> following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>

Chad Adams
Payback Training Systems
Email: cadams at cascadecc.com
Phone: 435-654-6304
fax:   435-654-1482



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)