[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Rules of Thumb for Creating XML Vocabularies for Workflow Applicatio
Costello, Roger L. wrote: > The list below contains guidelines for creating XML vocabularies for > workflow applications. In XML-based workflow applications the XML > documents are routed, and may be modified at various stops along the > route. > > RULES OF THUMB FOR CREATING XML VOCABULARIES FOR WORKFLOW > APPLICATIONS > > 1. An XML vocabulary does not exist in a vacuum. It exists for some > purpose or purposes. Is that not a given? Do you mean to convey the fact that the quality of an XML vocabulary may be judged by its fitness for purpose? I'd agree with that... > 2. An XML vocabulary must support the data needs of both the data > producers and the data consumers. Data producers are irrelevant - they have no needs. There are only the needs of data consumers. Sometimes a producer may also be a consumer, but they're distinct roles and should not be conflated. > 3. An XML vocabulary that is too generic will fail. Focus the XML > vocabulary to a specific purpose or (small) set of purposes. The single most critical factor, in my opinion. > 4. If there is markup (data) needed by the consumers but not the > producers then make it optional. Thus the producers can omit the > optional markup while the receivers can add it. You're conflating producers and consumers again. The original producer has a clear set of requirements for their downstream recipient. That recipient also has a clear set of requirements - augment the data and feed it to another process. It doesn't automatically follow that the original producer must have some knowledge about how the recipient intends to augment the data - ideally they wouldn't have a clue. If the recipient changes their requirements, should the changes really flow back to the original producer? You'd hope not... see point 3. > 5. Design flexibility and extensibility into the XML vocabulary, but > do not try to predict the future. Sounds good... > 6. Modularize the XML vocabulary. Create the XML vocabulary as an > assembly of building blocks ("data components"). As long as the assembly and understanding of the building blocks doesn't cause more overhead than what it's trying to solve. Sometimes for a well-defined system, it's just as easy to diff the schemas for the various processes as it is to manage the structures. > 7. Split out markup (data) that is optional and specific to the > consumers. One technique, for example, is for the consumer to add the > data that is specific to him in an envelope that wraps the producer's > data. The envelope topology is one approach to component-based > design; many others are possible and should be explored. I think that there are too many possibilities to bother trying to generalize. My guide would be to store the additional data in a way that makes it most fit for purpose for the immediate downstream recipient(s), but that doesn't say anything very helpful either. Marcus
[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
|