[
Lists Home |
Date Index |
Thread Index
]
MK> The XML spec gives some quite good clues as to what it was designed
for.
> "Its goal is to enable generic SGML to be served, received, and processed
on
> the Web in the way that is now possible with HTML." The design of XML
gives
> further clues: if they had wanted to design something that could be easily
> updated in-situ, they wouldn't have used a grammar that can only be parsed
> by starting from the beginning. The terminology also gives clues: a unit
of
> XML information is called a "document", not a "database".
>
OW> If all the parsing is done server-side, why does it matter? And if the
XML Management System can make tons of changes in-situ without parsing or
round tripping, then they have solved many of the bottleneck problems
associated with XML being used for something more than the strict definition
(whatever that is) of a document. NeoCore XMS does this.
I would suggest that the "document" metaphor fits perfectly for a
PurchaseOrder, CustomerProfile, Product Catalog and other like business
objects. Although developers think in business objects all day long, at the
end of the day most developers shred those rich objects into lots of little
cubby holes, or just serialize them and stuff them into a big cubby hole;
.and the richer (more complex) an object, the more relations required to
store it in the SQL world.
So am I storing documents? Yes.
Am I using XML instead of a database? Yes
I am merely suggesting there is a better way to store stuff, and that way
also happens to be leaving the XML in its native format.
> MK> I'm not talking about size, I'm talking about usage profile.
> I don't think that using an XML document as a replacement for a
> database is a particularly good idea
>OW>Evolution would call it a replacement
Revolution says there is a fundamentally better way, and that is not by
using a bunch of XIncludes pointing to references of stuff, or creating
documents that look perculiarly like RDBMS tables.
Instead, build a physical representation of your business objects in well
formed and semantically rich XML, and use those semantics and business
objects as documents to break free of the storage chains that currently bind
you.
> MK> If I had meant relational databases, I would have said relational
> databases. I have worked on many projects over the last 15 years that
needed
> much richer structures than relational databases offer.
>OW>How did you solve this rich structures storage problem in the past, and
what about XML precludes it from solving most if not all of these previous
issues?
> MK> I have no problem with the concept of XML databases, merely with the
> concept of trying to use a single 50Mb document as if it were a database.
OW> And now, I believe, we are at the crux of the problem. What or how
people use documents is nobody elses concern (and can lead to significant
competitive advantage :). That is why we have things like XSLT for
translations, and Rosetta and ebXML, etc. defining all these interfaces, so
you have a common language to talk with other systems; nobody says your have
to use those XML structures internally.
I am just saying, regardless of the schema of the XML (an industry standard
interchange or internal structures) why not leave it in XML? Why always
some other storage mechanism that either disassembles the XML or makes
querying, updating and deleting in place nearly impossible?
Maybe what we need are more verbs associated with XQuery than the implied
SELECT; otherwise, every XML database vendor will do it (Insert, Update,
Delete) differently, and in 10 years when everyone is using an XML database,
you won't be able to switch from one XML database to another as easily as
you can switch from Oracle to DB2 (assuming you don't use Oracles database
extensions: stored procedures).
MK> > (What I would really like to see is an XML database that gets rid of
the
> concept of "document" entirely. But we're a long way from that at the
> moment. In all the systems I've seen, the choice of "what is a document"
has
> a profound effect on both the physical and logical design, and as a
general
> rule of thumb, many small documents works better than a few large ones.)
OW> Maybe you should look at the Neocore XMS. It comes pretty close to what
you are asking, by cheating the system. Every document in the system is
<ND> and from there down the tree you have your own heterogeneous documents.
Not necessarily the cleanest way to obecure the concept of a document, but
this, combined with their capability to do insert, update and deletes both
within and across documents in-situ (no roundtripping), the "size" of your
document become irrelevant.
Owen
|
