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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [Fwd: Re: [xml-dev] XML Storage Architecture]


The following thread on xml-dev has some material describing our work. I 
am forwarding so that you can follow the
thread if interested.

Carl, would it make sense to scan the message to see if there is 
anything that needs to be included in our brochure. The brochure looks 
very good. Thanks for this valuable work.


-------- Original Message --------
Subject: 	Re: [xml-dev] XML Storage Architecture
Date: 	Sun, 14 Sep 2003 19:16:00 -0400
From: 	Farrukh Najmi <farrukh.najmi@sun.com>
To: 	xml-dev@lists.xml.org
References: 	<3F64043D.4090704@sun.com>

Jason Kohls wrote:

> We're looking at a content management system, which stores all of the 
> content/metadata in a single, 1 MB XML file on disk or as separate 
> records (for each parent element) in a two-field table in SQL, 
> out-of-the-box. Based on our rough content estimates, however, we can 
> see this file growing to over 100 MB easily.  The CMS provider says 
> that anything over 30 MB should use the SQL backend.
> The one thing that we do not like is the schema/data model (or lack 
> of) for the SQL storage option.  Coming from the relational camp, this 
> seems odd to us, and even on disk, hierarchically, it seems to make 
> more sense to break up this single XML file into smaller files (per 
> parent element) in a directory structure with an index.
> ...But then again, you guys are the experts :)
> Can anyone see any problems with this storage architecture from a 
> performance/stability/scalability standpoint?

Hi Jason,

You might consider using an ebXML Registry for your application. An 
ebXML Registry provides a standards based Content Management solution 
where a repository stores any type of content (including XML) and a 
registry stores standardized metadata
in an XML format. The registry provides classification of content using 
user defined taxonomies, association of content using user-defined 
associations. The registry is queryable using SQL-92 syntax as well as 
an XML filter query syntax. Automatic
content validation improve data quality, while automatic content 
cataloging improve data discovery.

A flexible content-based event notification capability allows clients to 
be notified when content of interest changes within the 
registry/repository. A loosely-coupled federation model allows different 
registry/repositories to cooperate with each other, share data and 
seamlessly inter-connect.

Security in an ebXML Registry provides authentication of clients based 
on digital signatures and authorization based upon flexible XACML Access 
Control Policies. Fine grained Role Based Access Control (RBAC) is fully 
supported via deployment specific roles and groups.

All of the ebXML Registry functionality is available over HTTP, SOAP or 
ebXML Messaging interface.

If you are interested in learning more then please join the ebxmlrr-tech 
mailing list at:


and post any questions on ebXML Registry there.  Thanks.


Related  Links:

[1] Project ebxmlrr: A Royalty Free Open Source Implementation of ebXML
Registry and JAXR (expecting major new release on Sep 15, 2003)

[2] http://www.freebxml.org

[3] ebXML Registry 2.1 Specifications (Approved OASIS Standard)

[4] ebXML Registry Technical Committee

[5] ebXML Registry V3 Specifications (interim TC approved version)

[6] ebxmlrr Presentations
Note: sxi format require free software from:



[7] ebXML Registry Presentations

Note: sxi format require free software from:


(detailed technical presentation)



[8] Java API for XML Registries



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]