OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: tpassin@home.com
  • To: <xml-dev@xml.org>
  • Date: Fri, 23 Jun 2000 21:35:11 -0400

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.

So we have

<table>
<row>...</row>
<row>..</row>
.
.
</table>

This is clean and simple.  Now, within the row, should each field be an
element or an attribute?   Here there is no obvious answer.  Eminent people
and organizations do it either way.  But there are some points that could
have you go one way or another.

- If order is important, don't use attributes.  Their order is never
guaranteed.
- If your field is going to have some structure of its own (possible in
newer flavors of relational databases), don't use attributes.  They can't be
structured.
- If your field is going to contain data that needs to be escaped with a
CDATA section, don't use attributes.  You can't use CDATA in an attribute's
value.
- If you want to include metadata about the field - datatype, ranges,
readonly status, update status, etc.,- it would be natural to put that in as
attributes, suggesting that the field itself should be an element.
- 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/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS