xml-dev - Re: XML Schema generation questions [was SQL schema to XML schema...]

["Mike Sharp" <msharp@lante.com>]

Forgive me for responding without snipping the posting I'm replying to, but I'm
unfortunately challenged with Lotus Notes, which does not allow inline
quoting...so I must do it manually.

<<<Therefore, it is natural - nearly mandatory - to represent a row as an
element. >>>

I suppose that if you wanted to represent the _schema_ of the database, it would
indeed be mandatory.  But if, rather, you were interested in the data for it's
own sake, you may want to represent it differently.  Relational databases are
limited to data in two dimensions--rows and columns.  They use the relationships
between tables to get the extra-dimensional aspects that real data has.  In my
opinion, you shouldn't hamstring your XML into a two dimensional world.  Of
course, if your goal is to simply pack the data in a database into XML for
transport, then this approach would work.  But you need some more stuff for the
metadata such as this column is a foreign key into that table. XML does provide
a mechanism for that, but I've never used it.

When I send data from the client to the server, because I've diagrammed the
relationship physically in the XML, I don't need to relate groups of tags, like
you would in the database.  The object layer infers those relationships.  I'm
pretty much of the opinion that you should hide linking tables and other
relational aspects of databases from the XML, unless there's a reason for it.

<<<- If you plan to try the Microsoft SQL Server 2000 Technology Preview, plan
for attributes, because that's what you will get.>>>

This was true for the early releases, but a demo of a new version that I
recently saw allowed you to specify either elements or attributes.  It also had
a mechanism to specify a combination of the two, but that seemed too complex to
me.  However, it could be done, and I haven't spent any real time on it.  I
believe they were actually calling it the SQL Server 8 Beta or pre-release
candidate or something, to differentiate it from the Tech Preview.  The original
tech preview also began to expose an API that you could call directly...but that
approach has been postponed to my knowledge.  They do have a thing called an
"XML View" which looked very interesting.  It was a way of exposing the data of
your database without exposing the schema, and seemed very object oriented to
me, at least in regards to the data representation.

I'm otherwise pretty much in agreement with the rest--not that my opinion
matters!  ;^)

Regards,
Mike Sharp

---------------------
Does killing time damage eternity? --KPIG





tpassin@home.com on 06/23/2000 06:35:11 PM

To:   xml-dev@xml.org
cc:    (bcc: Mike Sharp/Lante)

Subject:  Re: XML Schema generation questions [was SQL schema to XML schema...]



Bob DeRemer asked about table schemas -

>... I've generated "BizTalk" compatible schemas for each type (i.e.
> element-based and attribute-based).  I'm not sure yet, which approach is
> best.
>
> Being fairly new to XML (i.e. 3 months), I'm curious if others have done
> this before.  If so, what they have learned along the way.  My gut
instinct
> is to keep all columns as attributes, and each table is an element.
>

If you are concerned with relational database type tables, the fundamental
organizing feature is the row.  All queries return sets of rows, which in
turn may contain subsets of all the columns.  Joins produce sets of rows.
Views produce sets of rows.  Query conditions usually involve properties on
a row-by-row basis.

Therefore, it is natural - nearly mandatory - to represent a row as an
element.  This element would be inside another element representing the
table itself.

...

- If you plan to try the Microsoft SQL Server 2000 Technology Preview, plan
for attributes, because that's what you will get.
- If you plan to apply namespaces to a field, make it an element.  There is
no ambiguity about whether the namespace applies as there can be for an
attribute.

Overall, I favor using elements.  But there is no one answer.

Cheers,

Tom Passin





***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************