[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Why XML Over the Relational Model?

  • From: len bullard <cbullard@h...>
  • To: Paul Prescod <paul@p...>
  • Date: Wed, 06 Jan 1999 19:01:05 -0600

advantages of relational model
Paul Prescod wrote:
> 
> Good point. Interchange across the time dimension is very important.
> People who use a relational or object database for their day-to-day work
> should definitely consider backing up a periodic XML dump, just as people
> who use XML day-to-day should consider how those other tools can help to
> make it updatable, retrievable, searchable, etc.

Excellent thread.  Excellent.

All said then, we have pretty much the same answers we had in CALS:

o  Better interchange
o  Better lifecycle maintenance
o  Closer modeling to some real world structures such as *classical* 
   hierarchical documents
o  Flexible modeling for non-classical structures (if there are any)
o  Ability to combine approaches both in the model and in the
implementation

I agree with all that has been said.  During the SGML period, we
eventually 
wrote that hybrid systems for enterprises were idea because of the way 
people tended to capture certain kinds of information (they like to 
write in topical based, top forward ways) and because we could keep 
on using these instead of asking authors to view the worlds as Forms. 
There were also the advantages that where authoring systems used 
DTDs to parameterize the user interface, it was very easy to 
*guide* authoring processes toward required content types, and it 
was very easy to read the file and determine what was intended 
(tough to do with a table that spans more than a page as anyone 
who has seen a dump of a relationally implemented version of 
MIL-D-87269 can attest to). 

The markup model using a DTD is a nice middle of the road/practically 
anyone can learn to write one schema.  Relational modeling is certainly 
tighter given normalization, but it takes more effort.  Those who do 
both (markup and relational modeling) probably do both better 
as a result.

What I like about the tone of the answers to my question:

1.  Developers do understand the issues and do understand that the 
underlying implementation affects most of the benefits, that is, 
benefits of OOP vs file.
2.  Developers do understand the "horses for courses" approach 
and don't see everything in terms of XML.  
3.  Developers do understand the benefits of the lifecycle that 
markup can improve and do understand that exchange is a major plus.

Good.  Now, one additional benefit of markup as with any system 
that can use a schema is that the schema/DTD can be viewed as a 
contract/standard for information usage.   Seeing the other thread 
about architectural forms, we should lookat the role of the 
schema/DTD in standards processes and artifacts.  Many of us have 
done this and it isn't very hard to see the benefits.  However, 
the introduction of architectural forms to SGML was never completed 
in the sense that the community applied them or became comfortable 
with them.  Now that there will be alternative schema and design-DTDs 
such as SOX, we should consider these in terms of standards making.  

For example, the VRML NG effort is underway and there is a work item 
for creating a set of XML tags.  I have brought this up before but 
I think it bears repeating.  VRML 97 can be seen as a two layer 
specification.  The first layer is node based and defines the 
properties of the entities as node properties.   The second layer 
deals with the grammar as delivered (aka, the file format).  I 
think it possible that the upper layer could be considered an 
architecture.  If so, then isn't it possible to create standards 
from which other standards are derived by specifying, in this 
case, the property set as an architecture for Web3D applications from 
which the XML tag sets are derived?  Therefore, 3DML, Chrome, etc. 
could have different tag sets, but be derived from the same 
architecture and therefore be playable in a compliant engine?

However, looking at SOX, XML-DATA, etc and being reminded of the 
work done on the object-oriented MID version, I think it also 
possible that the same result could be achieved by these means 
as well given that in the end what is being considered is the 
fundamental property set which any application of the type must 
include.  

Given this, what approach is best for the making and 
maintenance of the standard?  Note I am not asking about 
implementation, but in the context of creating and maintaining a 
standard over its lifecycle.

Yes?  No?  Comments?

len

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.