XML schema size restrictions

Question

I was wondering what size restrictions there are on XML schemas? I'm developing a schema that has just raised the following error on registration.
ERROR at line 1:
ORA-31084: error while creating table "CAS"."swift564357_TAB" for element "swift564"
ORA-01792: maximum number of columns in a table or view is 1000
ORA-02310: exceeded maximum number of allowable columns in table
ORA-06512: at "XDB.DBMS_XMLSCHEMA_INT", line 0
ORA-06512: at "XDB.DBMS_XMLSCHEMA", line 151
ORA-06512: at line 828
On removing a few elements from the schema it registers fine, but querying the generated table swift564xxx_TAB there is only ever one column, typed with an ADT that itself only has 5 elements. In fact there doesn't seem to be, on the face of it, any type that has more than 20-30 elements. Where does this error come from then?
Unfortunately the schema exceeds the 20k limit on postings. I can split it up and post it in two parts if this would help.
Thanks
Marc

Answer 1

Each attribute in the ADT and each attribute of attributes which are an ADT count as one column
Here's a snippet from the next version of the doc that may help...
3-20 Oracle XML DB Developer’s Guide, Rel. 1(10.1) Beta 2 Draft
A number of issues can arise when working with large, complex XML Schemas.
Sometimes the error "ORA-01792: maximum number of columns in a table or view
is 1000" will be ecountered when registering an XML Schema or creating a table
based on a global element defined by an XML Schema. This error occurs when an
attempt is made to create an XMLType table or column based on a global element
and the global element is defined as a complexType that contains a very large
number of element and attribute definitions.
The errors only occurs when creating an XMLType table or column that uses object
relational storage. When object relational storage is selected the XMLType is
persisted as a SQL Type. When a table or column is based on a SQL Type, each
Registering an XML Schema with Oracle XML DB
attribute defined by the Type counts as a column in the underlying table. If the SQL
Type contains attributes that are based on other SQL Types, the attributes defined
by those Types also count as columns in the underlying table. If the total number of
attributes in all the SQL types exceeds the Oracle limits of 1000 columns in a table
the storage table cannot be created.
This means that as the total number of elements and attributes defined by a
complexType approaches 1000, it is no longer possible to create a single Table that
can manage the SQL Objects generated when an instance of the Type is stored in the
database.
In order to resolve this problem it is necessary to reduce the total number of
attributes in the SQL Types that are used create the storage tables. Looking at the
schema there are two approaches that can be used to achieve this:
The first approach uses a ’top-down’ technique that uses multiple XMLType
tables to manage the XML documents. This technique reduces the number of
SQL attributes in the SQL Type heirarchy for a given storage table. As long as
none of the tables need manage more than 1000 attributes the problem is
resolved.
The second approach uses a ’bottom-up’ technique that reduces the number of
SQL attributes in the SQL Type herirarchy collapsing some of elements and
attributes defined by the XMLSchema so that they are stored as a single CLOB.
Both techniques rely on annotating the XML Schema to define how a particular
complexType will stored in the database.
In the case of the top down techniqueby the annotations SQLInline="false" and
defaultTable are used to force some sub-elements within the XML Document to
be stored as rows in a seperate XMLType table. Oracle XML DB maitains the
relationship between the two tables using a REF of XMLType Good candidates
for this approach are XML Schemas that define a choice where each element
within the choice is defined as a complexType, or where the XML Schema
defines an element based on a complexType that contains a very large number
of element and attribute definitions.
The bottom up technique involves reducing the total number of attributes in the
SQL object types by choosing to store some of the lower level complexTypes as
CLOBs, rather than objects. This is acieved by annotating the complexType or
the usage of the complexType with SQLType="CLOB".
Which technique is best depends on the application, and the kind of queries and
updates that need to be performed against the data.