Cart
[Home] [By Thread] [By Date] [Recent Entries]
> ... should also be business as usual; interview, map data flows, > model the data domain; abstract / normalize, validate the design with > the SME and other users; iterate again until you have it close enough > for a prototype then do the same thing all over again until your > prototype has grown up into a real application. The fact that you're > using XML should not change the way turn requirements into an logical > architecture. Should data be designed for specific applications? Or, should data design be a matter of documenting a cow path? I understand best when I see specific, concrete examples, so let me provide one. Suppose I interview several Book SMEs. They tell me that a Book is comprised of a Title, Author, Date, ISBN, and Publisher. I document this data and the relationship (parent-child relationship between Book and Title, Author, Date, ISBN, Publisher) in a Book Data Specification. The Book Data Specification is handed off to a techie who then creates an XML Schema implementation and several sample XML instances. There may be several iterations to get any confusion cleared up. I end up with an XML Schema that is independent of any specific application. Thus, it supports the unanticipated user. I don't see data flows, application architecture diagrams, or business processes entering into the picture at all. It seems to be simply a matter of identifying the data cow path, documenting it, and implementing it with an XML Schema. What and how applications use the resulting XML instances is outside the scope of the Data Specification - XML Schema Implementation activity. No? /Roger
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
