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?
Ross