[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: [Summary] Should Subject Matter Experts Determine XML Data
Hi Folks, Thank you very much for your excellent comments. Below is a summary of what I've learned. What would you add to this list? What would you change? 1. It is important to get inputs from a diverse set of people when creating a Data Specification and when evaluating an implementation (e.g. XML Schema). Different people have different perspectives on the information. Never assume that any one person has the whole picture. Get inputs from Subject Matter Experts (SMEs), technology experts (TEs), users of applications that will use the data, and business people. 2. Be careful of loose, ambiguous terminology. The Data Specification must provide clear, unambiguous definitions of the data. 3. One or more implementations are derived from a Data Specification. An implementation may or may not be a 1:1 mapping of the Data Specification. For example, a Data Specification may describe the data in a traditional parent-child format, whereas the implementation may be an RDF document. A Data Specification implementation may be incorporated into a broader activity which requires a generalization of the data. For example, Book data that is specified in a Book Data Specification may be incorporated into a larger multimedia interchange format, perhaps requiring "Book" to be generalized to "Product." 4. If there is not a 1:1 correspondence between an implementation and the Data Specification, then there must be a way to map between the implementation and the Data Specification. This is important for traceability. 5. When implementing a Data Specification, a technical expert must take into consideration the kinds of processing that applications are expected to perform on the data. Certain data designs may make processing horribly inefficient, while other designs can make processing very efficient. For example, below is a snippet of two data designs of a grape vineyard. There are Pickers on the vineyard: DATA DESIGN #1 <Lot id="1"> <ripe-grapes>4</ripe-grapes> <Picker id="John"> <metabolism>2</metabolism> <grape-wealth>20</grape-wealth> </Picker> </Lot> <Lot id="2"> <ripe-grapes>3</ripe-grapes> </Lot> DATA DESIGN #2 <Lot id="1"> <ripe-grapes>4</ripe-grapes> </Lot> <Lot id="2"> <ripe-grapes>3</ripe-grapes> </Lot> <Picker id="John" locatedOn="1"> <metabolism>2</metabolism> <grape-wealth>20</grape-wealth> </Picker> If the primary processing activity is to *move* the Pickers from Lot to Lot, then Design #2 is more efficient because moving a Picker simply involves changing the locatedOn attribute. If the primary processing activity is to *search* for Pickers on a Lot then Design #1 is more efficient because finding the Pickers on a Lot is simply a matter of selecting the Lot and then looking for child Picker elements. A technical expert must take into consideration the types of processing that will be done on the data and optimize the data design for that processing. /Roger
[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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|