W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2008

RE: Impact of XML on Data Modeling

From: Tsao, Scott <scott.tsao@boeing.com>
Date: Tue, 29 Jan 2008 20:33:28 -0800
Message-ID: <C7A7D8EA54C20744BFF861613617222C06218E9B@XCH-NW-3V1.nw.nos.boeing.com>
To: "Essam Mansour" <essam.mansour@gmail.com>, "Michael Kay" <mike@saxonica.com>, "Bob Schloss" <rschloss@us.ibm.com>
Cc: <xmlschema-dev@w3.org>
First of all, I would like to thank those enthusiastic people who
quickly responded to my original inquiry.  
 
I am taking the liberty to except from your replies the most useful
comments that seem to help me better understand the issues involved:

*	
	"These three concepts have been addressed very well in the area
of DB data modeling... However, in the area of XML, I did not come
across any paper regarding that." - Essam
*	
	"I agree with you that 'I would say that an XML schema would
correspond to the logical data model' because XML schema is based on a
specific model and at the same time is platform-independent." - Essam
*	
	"Logical model would have to be expressed in some concrete
modelling language... - 3NF relational models and XML schemas being two
of the many candidates (others being object models, entity-relationship
models, etc)." - Mike
*	
	"3NF models of course are much more suitable at the database
level than at the data interchange level. Message design needs
hierarchic models which is what makes XML so suitable. And the data
interchange level these days has much more strategic importance than the
database level, because it's all to do with optimizing business
processes and value chains." - Mike
*	
	"I'd say that an XML binding...is a mapping between two
different logical models of the same data." - Mike
*	
	"An XML schema is a physical data model... By contrast, [a
logical data model could be] the equivalent UML logical data model (for
the same information as the schema) [which] would describe the same
data, but not low-level issues like elements versus attributes. " - Tony
*	
	"The conceptual model should be the business experts view of the
problem, using their terminology and their way of viewing things.  The
logical model should be the technicians view of teh solution, using
their terminology and their way of viewing things... If the conceptual
model turns into something that is more technically formal and proper,
but less understandable to the business experts, then its value is
lost." - Tony
*	
	"I don't really buy the idea that abstractions can be classified
as business-oriented or technically-oriented. They arise from designing
IT-enabled business processes, which tends to be a joint activity." -
Mike
*	
	"I wasn't suggesting that abstractions are forcibly
technically-oriented. However, I was suggesting that people with a
technical mindset tend to create models with more abstractions (i.e.
data normalised into common superclasses) than do people with a more of
a business mindset... Beware though that if you train today's business
experts to understand structures and terminology that you have
introduced, that is not based on their day-to-day experience and
language, then you need to be able to repeat that training for any new
business experts who may replace them." - Tony
*	
	"I haven't found it practical to draw rigid distinctions between
logical and physical models." - Bob
*	
	"Regarding conceptual models, I agree that they are most
valuable when communicating with business or regulator stakeholders that
you can't convene in a meeting for a syncronous dialog." - Bob
*	
	"In the relational modeling world, there were clear procedures
to refine logical models into physical models." - Bob
*	
	"Because of the broad interest in SOA, I think a new frontier
are tools that combine a data modeling perspective with a process
modeling perspective." - Bob

Based on the comments above, I came to the following conclusions so far:

*	
	3-schema architecture for data modeling seems be a practical and
useful methodology in the 'relational' database world, e.g., from
business objects to ER to 3NF to DDL for RDBMS, etc.
*	
	In the XML world, however, the distinction among those 3 levels
of abstraction seems to be artificial and overly constraining.
*	
	XML is a better approach for design and implementation at the
data interchange level, e.g., specifying the interface 'protocol'
between two systems (or applications).  For example, in the SOA world,
XML would be very useful as the common modeling 'language' across the
data and process modeling perspectives.
*	
	(did I miss anything?)

If these observations are correct, my next question would be: Is the W3C
XML Schema the best choice on the market today for data modeling in the
XML world?  (why or why not)
 
 
Thanks,



Scott Tsao 
Associate Technical Fellow 
The Boeing Company 

 
 
 
 
Received on Wednesday, 30 January 2008 04:35:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:15:01 GMT