Adding to Jeffries....

There are some other considerations that need to be addressed....as below


>-----Original Message-----
>From: Ron Jeffries [mailto:ronjeffries@...]
>Sent: Monday, March 19, 2001 7:11 AM
>To: extremeprogramming@yahoogroups.com
>Subject: Re: [XP] Question about YAGNI and DTSTTCPW
>
>
>Responding to Paul Michali (08:55 AM 3/19/2001 -0500):
>>So does the parse take the records and pack them into struct that
>the program
>>then uses?
>
>The provided parsers usually provide strings to your program on callbacks
>and you can do what you want. Building a struct or object
>representation is
>common.

You may what to think about a class structure that has Helper Classes (a
Java concept) that a called when each node in the DOM is encountered. We've
used these to advantage, since situational parsing is needed in many cases,
especially in non-validated XML streams.

>>How does one access a specific record (say the 100th)? Does one include a
>>tag with some unique record identifier (or number)?
>
>This would be possible. There are also attributes like <RECORD ID='0001'>.
>Or you could count. Or you could be relational and just not care ...

I would suggest that if your thinking of persisting XML and using is as a
"database substitute" DON'T. Mapping XML to tables is the standard way to do
this. Take a look at Building Oracle XML Applications or Professional XML
Databases, both I would recommend. The first is authored by the Oracle XML
guru and the second is a Wrox publication (which is usually high value
content).

The issues of persisting XML in relational databases needs to be examined
several perspectives? Is this going to be a true database application? If so
then database "thinking" should take place, and some "robust" processes need
to take place. If the XML is transitory or there just for the "fun of it"
then suggestions like Ron's (just not care...) may be appropriate.

There are flexibilities in the XML persistence world, but they can come back
to bite you if you don't think ahead a bit.

The one BIG issue is with DOM parsers, they are memory resident and suck
resources. If the XML your handling is small and simple, then DOM might be a
good place to start. SAX parsers are now available and are not memory hogs
and handle large complex streams.

>>Would all this XML be stored in a disk file as the database?
>
>I think that's what people were suggesting when they suggested
>using XML as
>your database, yes.

Be careful of the allure of XML databases, like OO databases before they are
just starting out. Oracle 8i, 9i, and beta 10i all support XML persistence
is some degree. MSFT has there versions as well, but we're a SUN/Oracle shop
so I can't speak to their capabilities as well.

>Cons: It seems to take a lot of space.
>
>Pros: It is very flexible. A program that doesn't care about some
>new field
>never has to see it.

Maintaining semantic consistency over time becomes a problem for
uncontrolled semantics. Be aware that the allure of "XML independence" turns
into XML Nightmares when unknown tags start to saturate the streams. What
are you supposed to do with the tags when creating objects in a database?
When do they go? How are the "unknowns" reported to the persistence engine?


>The file is human-readable, which is very valuable in
>early days of building up database kinds of programs.

In practice XML become unreadable very quickly. This "readability" is a
selling point of XML that evaporates on the first production system.

We fell into all of these "marketing traps as well." We BIG XML users
through newsML (www.itpc.org), but like all new technology it looks simple
and powerful on the surface and turns out to be powerful and complex in the
end, when you add robustness, fault tolerance, forward error correction (DTD
break and have to be rebuilt, but now don't match the original semantics)...

Take a look at www.xml.com and the IBM AlphaWorks site for parsers, SAX, and
all kinds of working examples of how to use XML in ways it way never
designed for. Just remember to sort out the usage into "text presentation"
and "data markup." Try not to get these tow mixed or you'll have a real
mess.

Glen Alleman
Niwot Ridge Consulting

"Go for synergy! When two agree, one is unnecessary." – Steven Covey