Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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] |
