Re: [xml-dev] Caught napping!

[PaulT <pault12@pacbell.net>]

----- Original Message -----
From: "Sean McGrath" <sean.mcgrath@propylon.com>

> Right. And your CTO (if s/he has been around long enough and understands
> human nature) knows that the database contains things like:
>
> Name:           Sean McGrath
> Id:             12345
> Notes:          Last contacted 1/1/2001. Joe from Sales I think - ask
>                  Shiela.
>                  N.B. Contact before 2002 for upgrade. See foo.doc
>                  for history.

After 1 minute of thinking ( please don't
consider it to be a 'design',  just a 'view', because
designing a convinient and scalable system like this
implies understading of the problem domain, to
generalize properly e t.c. BTW - anyway you have
to do that step, is it SQL or XML. In the case of
XML you have to think about 'what are the tags',
right? )

So it could be

Name: Sean McGrath
Id:    12345

Notes:

Note1:

What : Last Contacted:  1/1/2001
Comment: Joe from Sales I think - ask Shiela.

Note2:

What: Contact Before:  2002
Comment: for upgrade

Note3:

What: Link : foo.doc
Comment: history

This is just a quick possible solution how to
support semi-structured data ... And it could
be implemented not adding a single column to
the database.

I can not belive somebody may think that adding new
property implies adding new column to some table.
Like any typical web-developer, I've implemented
several systems when the number, names and types
of properties are not known in advance.

Systems like Documentum and CMS do that
for ages and .. they're doing fine ... Big clients,
lotsa money.

Usually you  just provide a heap of properties,
linking them to the parent with a simple join. As to
(early mentioned) cases of 500 tables joins - I'd
like to think that 500 tables joins is not the case in
the real life, but after some SQL schemas that
I've seen in the US, I'm not so sure on this one ...

Still, I think joins of 500 tables is not what we
see every day ;-)

> Over time, much good stuff migrates into free format areas such
> as notes fields in RDBs. Why?  Because RDBs just don't cater for
> semi-structured evolution. Ever ask a DBA to add a field to a
> table?. If not, bring a helmet and ear-plugs when you do.

This is *almost* irrelevant, because adding new properties to
the object *does not* imply adding a new column to the table.
Blame stupid coders. Well not really. See below.

> RDBs don't evolve well. The mathematical elegance of RDB is lost
> in a crazy world of economic cycles and messy, experimental
> business models that rewards adaptability over mathematical
> elegance.

Nope. RDBs don't envolve well usually because
most of SQL schemas are a *plain* shit,
when people are denormalizing data to optimize on
joins ( and usually bottlenecks are *not*
on that part, but somewhere else ). Well, not really.
See below.

> Evolution is the natural state of all systems. XML is easier to
> evolve.

Proof?
Proof???

I have a hard time with linking. SQL gives linking
for free ( just join by 'id' - and you can link anything
with anything ). With XML it may look easier to
add one more property ( that's why it looks
'easeir to envolve' ), but when you want to link
something - bang. Earlier in this discussion, there
was a good point about how to keep PO 'in sync'.

What is 'easier to envolve' ? What  is ' to envolve' ?

> Less "optimal", less beautiful but easier to evolve. I
> know which one Darwin would put money on.

Nope.

1. XML has no reasonable model behind it.
( where it is? where is the math, 'mapped'  into
some real stuff ( like it is with SQL and/or regexprs),
 the stuff that I can run on my computer? )

2. XML is *not* easeir to envolve ( linking. And not only.)

Well. Not really. See below.

> I have worked in many organizations with "bright shiny
> RDBs. Invariably, although
> the database plays an important role, the *real* knowledge is not
predicate
> logic assertions in Oracle but hunches and bitter experience and
initiative and
> half-remembered, half-imagined facts. In short the real knowledge
> in any organisation is in peoples heads. If you are lucky, your people
> will write down stuff in faxes, word docs and notes scribbled into the
margins
> of your beautifully elegant but woefully unsuitable for your business,
> relational database record structure.

So? I don't get it. Most of developers produce crappy SQL
schemas, even they're using ( relatively ) elegant and
simple SQL mechanizms.

You think the same people will do better with XML ?
I know they will not. You know they will not ;-)

> Does XML solve this problem? No.

OK! So we agree here. People writing bad SQL code -
will write bad XML code as well. Let's see the next step ...

> But it might be a better source
> of fundamental compounds from which to craft a solution to
> the problem.

???

> All we know for sure is that RDB does not solve
> the problem.

This is really strange logic. And this is the
'see below' part also. ;-)

Yes, we know that RDB does not solve the problem.
Honest.

But I'd put it slightly different.

"Almost all current SQL servers - kinda suck".

I can elaborate why, but that's not my point.
( Also I should say that I use SQL
servers all the time and I think that
SQL servers are the most valuable asset
in current IT, together with regular expressions
and Yacc. ;-)

My point is that the statement above does
*not* equal to "RDB does not solve the problem".

Why do we 'feel bad' with current SQL servers ?
There are many reasons, I think.

Maybe, just relational model sucks.

Unfortunately, I doubt that there is many people
on the planet, who *really* understand how
relational model could be *possibly* applied
to DBMS.

What we know now as SQL, is not the
'true' relational model, but there is something taken
by big guys, who have cooked commercial products,
several 'standards' e t.c.

I'm not saying that SQL as we know it is 'bad'
implementation of 'good mathematics'. I'm just
sure that it is just *one* of possible
implementations / mappings, so we can not
judge the model by the implementations that
we have.

It would be like judging markup languages by
SGML, saying 'markup languages are too heavy'.
We now have XML, right? ( And XML is not
the end for sure ).

However, with all the differences between SGML
and XML, they are just different reflection of the
same 'model'. Right? I think the same is with
relational model and SQL servers.

I'd really love to hear what Fabian Pascal has to say,
when he's saying that "the real invetion has happened,
but nobody noticed", when he talks about the relational
model.

Unfortunately, when somebody can not tell the truth
in one page ( I tried to understand what
Fabian syas, but I've failed)  that may mean that there
is *no* truth. But that also could be that there *is* a truth,
which is just  *hard to express*.

It takes ages to get a 'simple' things clean. It took
*years* for UNIX guys to 'invent'  the '|' symbol !

Just a stupid '|' symbol!

> All the word docs and faxes and scribbled
> marginalia in all the filing cabinets in all the world
> attest to that fact.

It all does not matter. Really. People always
do things in stupid ways and the fact that
"SQL servers don't do the trick" is *irrelevant*
to evaluation of XML servers.

At least SQL *has* some model and it turned
out that some aspects of that model are handy
for processing and /or 'writing code'.

 'join' ( link anything with anyhthing ) is
the shining argument.

Somebody claims that XML has a model, which
is handy for processing and / or 'writing code' ?

Well, it could be that XPath is such a
shining argument. In fact I think that it is
the *only* possible argument, but XPath
is not benefiting from XML model, it
struggles with it, working many things
around.

So, what I wanted to tell was:

1. Yes, I think I also feel that
'there is something not really good with
the current SQL servers'

2. It has *nothing* to do with the
(possible) ... questionable ... sucess
of XML servers.

3. I have a strong feeling that
'poor man'  "XML server" ( I'm talking
XML subsets!!!) can perfectly live on
top of SQL server.

Would that mean that such a server is a
clear proof that "SQL can express XML",
but "XML can *not* express SQL",
and that will finally show that
SQL model has won? ;-) Just kidding.

Rgds.Paul.