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

RE: Were these derived from a logical data model: XSLT, XML Sc

  • From: "Michael Kay" <mike@s...>
  • To: "'Costello, Roger L.'" <costello@m...>,<xml-dev@l...>
  • Date: Sun, 16 Mar 2008 19:02:27 -0000

RE:  Were these derived from a logical data model: XSLT
> I took a look at the XPath Data Model [1].  It's all prose.  
> There are no UML-type diagrams.

That's purely an editorial issue, of how people choose to describe and
publish the model.  
> 
> In fact, I can't find any documents on XSLT, XML Schema, 
> XHTML, or Schematron that contain UML- or ER-type diagrams.  
> The documents are all prose. 

I think there's a considerable reluctance to use diagrammatic notations in
standards or in W3C specifications. One reason may be because the tools for
creating the diagrams are proprietary and often expensive, or it may result
from a feeling that diagramatic notations are useful as an aid to
comprehension, but poor as a vehicle for formal and unambiguous
specification. There may also be a reluctance to assume that the reader is
familiar with the detailed conventions. Also, committed use of UML can lead
to a lot of unproductive debate about whether or not a particular
relationship, for example, should be modelled as an "aggregation" or not: in
the end, it doesn't matter.

The fact that diagrams aren't used in the spec doesn't mean they weren't
sketched on a whiteboard or in a notebook while the model was being
designed: there's no way of knowing. I've got masses of data structures in
Saxon that were once doodled on a scrap of paper, but there's no external
evidence of this.

> 
> As far as I can tell, the "logical data model" used to create 
> an XML vocabulary is different than the "logical data model" 
> used to create a database- or object-system.

It may or may not be. Many people do create UML models before defining XML
schemas. Where you have to analyze a complex subject domain this makes
excellent sense. But as has been pointed out in another recent thread on
this topic, you have to be careful because the content of an XML message
depends on the process model as well as the state model: the fact that every
customer has an address doesn't mean that the address has to be present in
every message that refers to the customer.
> 
> Here are the differences that I see:
> 
> Creating a database or object system involves:  
>    . create UML- or ER-type diagrams, and then 
>    . create the database or object system directly 
>      from those diagrams. 

That's the textbook theory. In 99% of cases people take shortcuts. In the
other 1%, the project goes over budget. 

Michael Kay
http://www.saxonica.com/



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


PURCHASE STYLUS STUDIO ONLINE TODAY!

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

Buy Stylus Studio Now

Cast Your Vote

We need your help – Vote for DataDirect XML Products!

  • Best SOA or XML site

Winners and finalists announced at SOA World Conference in November.

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-2007 All Rights Reserved.