[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
Roger, The context for my comments comes from industry standards-setting activities, concentrated in the chemical and agriculture industries. I suspect that my comments would apply to similar activities within a company, but I have little experience with that. Many of my comments are common sense so take them as potentially worth adding to your list rather than telling you something you didn't already know. Best regards, Jim Wilson CIDX Chief Architect > -----Original Message----- > From: costello@m... > > 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. Agree. Some comments: a. I agree that it is important to get inputs from a diverse set of people. I also think it is important to do so in a group setting so that the input can be discussed, other perspectives understood, and consensus reached. b. Employ a facilitator who is a business-minded TE. Domain expertise is not required (and can be an impediment). This person must be comfortable leading a discussion about process and data (see next comment), must be adept at hiding the complexities of XML while still exposing the hierarchical, cardinality, and basic data type aspects of the data requirements that are intuitive to SMEs. c. Ultimately data implementations support processes. Sometimes it's important to agree on processes before discussing the data. Sometimes discussing data first helps people recognize a process-alignment issue. d. Don't underestimate the importance of tools, room setup, and roles in a session. For example, I find TurboXML a more effective schema editor in a group setting than other XML editors or text editors (my preference for work on my own). Also, for example, having two projectors--one for the schema and one for the data dictionary/glossary is very helpful. With respect to roles, find the best note taker and put them in charge of the data dictionary/glossary. e. Implementers appreciate naming and design rules that lead to consistency and they are willing to compromise on naming and design preferences to support consistency. The choice between "ProductID", "ProductId", "ProductIdentifier", "ProductNumber" should be dictated by naming and design rules, not the person with the strongest preference. f. Finally, avoid code list maintenance/architecture discussions. The topic seems so intuitive and inviting that every rookie thinks they have the solution to the "simple problem". Work in this area continues today by veterans (eg, UBL and UN/CEFACT). Code list maintenance/architecture discussions are a time sink and are best left to TE discussions over a pint of Guinness. > 2. Be careful of loose, ambiguous terminology. The Data Specification > must provide clear, unambiguous definitions of the data. See my comment in 1.d. Additionally, I find that demanding precise terminology and definitions along with encouraging documenting lots of notes and examples is very helpful in the long run. In particular, noting distinctions and relationships between concepts is helpful. The more successful an XML data implementation becomes, the more likely it is that it will be revisited in the future for extension and application in other contexts, at which point the value of the notes and examples is really appreciated. > 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. Agree. See note for #5. > 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. "...technical expert take into consideration..." I think is the right role engaged in the right activity. I've experienced all too often teams that get bogged down in performance speculations (eg, schema too big; element names too long; nesting too deep; code list values too many characters; xsd:maxOccurrence='unbounded' not changed to a "reasonable" value). Often, simple performance tests shatter performance assumptions--assumptions that if addressed would lead to awkward designs (from semantic perspective, at least) and almost always waste valuable team time in discussions. Who cares if a desktop application processes data in 500 milliseconds vs. 5 milliseconds (with an alternative design) twice a day? My default perspective is that if performance and bandwidth are critical concerns, then XML may not be the right syntax for you. Having said that, there have been occasions where performance really was an issue that could be addressed by design changes. One other comments about performance relates to #3. Often I find that a design decision made for one implementation optimization results in a performance degradation for another implementation.
[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
|