[Summary] Keep business-process-specific data separate?
Hi Folks, Below is a summary of our discussion. I first present the transportation example, show the conclusion, and then analyze the conclusion to explain why it's false. The analysis contains general principles for creating XML vocabularies. Please notify me of errors. /Roger CASE STUDY Create an XML vocabulary for a transportation request. OBJECTIVES Explore the role of business-process-specific data when creating an XML vocabulary. Specifically, should business-process-specific data be included in an XML vocabulary? TRANSPORTATION TASK REQUEST XML VOCABULARY I am assigned the job of creating an XML vocabulary for a "Transportation Task Request." Here's an example that shows what I created: In the following instance document I am expressing the desire to be picked up from my home on January 29 at 7 am and dropped off at Logan airport. On my return trip I desire to be picked up at Logan airport on February 4 at 6 pm and dropped off at my home: <Transportation-Request> <Departure> <Starting-Point>home</Starting-Point> <Finishing-Point>Logan airport</Finishing-Point> <Datetime>2009-01-29T07:00:00</Datetime> </Departure> <Return> <Starting-Point>Logan airport</Starting-Point> <Finishing-Point>home</Finishing-Point> <Datetime>2009-02-04T18:00:00</Datetime> </Return> </Transportation-Request> THE BUSINESS PROCESS THAT THE XML VOCABULARY IS USED IN A user will create an instance document using the above XML vocabulary and then walk it over to the company's transportation office and give it to them. The first thing they do with it is stamp on it the date and time of submission. INCLUDE A SUBMISSION DATETIME ELEMENT? When I created the Transportation Task Request XML vocabulary, I asked myself: Should it include a <Submission-Datetime> element? That is, when a user creates an instance document, should the document include an empty <Submission-Datetime> element: <Transportation-Request> <Submission-Datetime></Submission-DateTime> <Departure> <Starting-Point>home</Starting-Point> <Finishing-Point>Logan airport</Finishing-Point> <Datetime>2009-01-29T07:00:00</Datetime> </Departure> <Return> <Starting-Point>Logan airport</Starting-Point> <Finishing-Point>home</Finishing-Point> <Datetime>2009-02-04T18:00:00</Datetime> </Return> </Transportation-Request> When the transportation office receives the instance document, they can fill in the element. I pondered: Is this a smart thing to do - include a <Submission-Datetime> element in my Transportation Task Request XML vocabulary? BUSINESS-PROCESS-SPECIFIC DATA Recall my objective: create "an XML vocabulary for expressing a transportation task that I want accomplished." The <Submission-Datetime> element is not relevant to my objective. The <Submission-Datetime> element only comes into play when a transportation request document is given to the person at the transportation office. That is, the <Submission-Datetime> element is only relevant in this particular business process. The <Submission-Datetime> element is business process-specific data. CONCLUSION: AVOID BUSINESS-PROCESS-SPECIFIC DATA I conclude that it's bad to include business-process-specific data with my XML vocabulary. My rationale is that in another business process the <Submission-Datetime> element may not be relevant. For example, in addition to dropping my document off at the transportation office, I also drop a copy off at human resources. The first thing the HR office does is stamp my name on it. Thus, in this business process, the <Submission-Datetime> element is not needed; rather, a <name> element is needed. By keeping business-process-specific data decoupled from my XML vocabulary it gives me flexibility to use my XML vocabulary in a variety of business processes. ANALYSIS The conclusion is false. Let's see why. 1. An XML vocabulary does not exist in a vacuum. It exists in a context. Specifically, it exists for the purpose of enabling a business process. The transportation XML vocabulary was created for the purpose of enabling the transportation office to provide a limousine service for its employees. 2. If an XML vocabulary does not support the data needed by the business process then it is not serving the very purpose for which it was created. The date and time that a transportation request was submitted is required for the transportation office to provide its service. By failing to provide a <Submission-Datetime> element I have failed to support the transportation service that my XML vocabulary is supposed to support. 3. "Business-process-specific data versus business-process-independent data" is a false distinction. There is only kind of data: data for a business process, and there is only one kind of XML vocabulary: vocabulary that supports a business process. The <Submission-Datetime> element is just as important as all the other elements. They all are used to support the employee limousine service. 4. An XML vocabulary must support the data needs of both the data producer and the data receiver. The transportation XML vocabulary must enable the person making the travel request to provide his/her data, and it must enable the transportation office to meet its needs by adding a stamp for the date and time of submission. 5. If there is markup (data) needed by the receiver but not the producer then make it optional. Thus the producer can omit the optional markup while the receiver can add it. Remember: we're not dealing with a relational database, we're dealing with XML documents. Just because an element is part of the vocabulary doesn't mean the data producer has to include it in every document created using that vocabulary. It can be optional and the data receiver can add it. The person making the travel request has no use for the <Submission-Datetime> element so make that element optional when creating the XML vocabulary. The transportation office will add it when the travel request document is received. 6. The conclusion that I came to in my transportation example - keep business-process-specific data separate - is false, for the above reasons. 7. You may be wondering about the HR department and my statement: By keeping business-process-specific data decoupled from my XML vocabulary it gives me flexibility to use my XML vocabulary in a variety of business processes. Let's analyze this: Why do users also drop off a copy at human resources? If it's a company requirement that they do that for every travel request, then that's part of the *same* business process, rather than a different one.
[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