"Ross J. Reedstrom" wrote:
>
> On Sun, Jul 29, 2001 at 12:19:48PM -0400, mlw wrote:
> >
> > <employee>
> > <name>Bill</name>
> > <position>Programmer</position>
> > <address>
> > <number>1290</number>
> > <street>
> > <name>Canton Ave</name>
> > </street>
> >
> > <town>
> > <name>Milton</name>
> > </town>
> > </address>
> > </emplyee>
> >
> > The above is almost impossible to convert to a relational format without
> > additional information or a good set of rules. However, we can determine which
> > XML titles are "containers" and which are "data." "employee" is a container
> > because it has sub tags. "position" is "data" because it has no sub tags.
> >
> > We can recursively scan this hierarchy, decide which are containers and which
> > are data. Data gets assigned an appropriate SQL type and containers get
> > separated from the parent container, and an integer index is put in its place.
> > For each container, either a primary key is specified or created on the fly.
> >
> > We insert sub containers first and pop back the primary key value, until we
> > have the whole record. The primary key could even be the OID.
> >
> > A second strategy is to concatenate the hierarchy into the field name, as
> > street_name, town_name, and so on.
> >
> >
> > What do you think?
>
> What about attributes on tags. They're data, certainly. Do they then
> promote the tag they're in to a container?
Attribute tags are normally something you should know about before hand. There
has to be a number of tags which do not force a container.
This whole thing depends on a good DTD.
--
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com