1 Rules of Thumb for Creating XML Vocabularies for Workflow Applications February 1, 2009

2 Contents Definition of "workflow applications" Case study Lessons learned/rules of thumb Acknowledgements

3 Workflow Applications In XML-based workflow applications the XML documents are routed, and may be modified at various stops along the route: XML Rob SallyPete JillAnthony

4 Case Study I am assigned the job of creating an XML vocabulary for a "Transportation Task Request." On the following slide is an example that shows what I created.

5 My XML Vocabulary "I 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." home Logan airport T07:00:00 Logan airport home T18:00:00

6 Usage 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 the transportation office does with it is stamp on it the date and time of submission. home Logan airport T07:00:00 Logan airport home T18:00:00 RECEIVED Jan. 28, 2009

7 Add a Submission Element? When I created the XML vocabulary I asked myself: Should it include a element? That is, when a user creates an instance document, should the document include an empty element? See example on next slide

8 Empty Element home Logan airport T07:00:00 Logan airport home T18:00:00

9 Good Idea? When the transportation office receives the instance document, they can fill in the element. Is this a smart thing to do?

10 Recall My Objective Objective: create an XML vocabulary for expressing a transportation task that I want accomplished.

11 Bad Idea! The element is not relevant to my objective. The element only comes into play when a transportation request document is given to the person at the transportation office.

12 No Submission Element I decided not to include a element in my XML vocabulary. The transportation office can create their own XML vocabulary that adds a element. Thus, my XML vocabulary is flexible: each office that receives an instance of my XML vocabulary can add their own unique markup/data.

13 Conclusion Keep business-process-specific markup/data separate from my XML vocabulary.

14 My conclusion is false! Let's see why …

15 Lessons Learned & Rules of Thumb

16 1. Must Have a Purpose An XML vocabulary does not exist in a vacuum. It exists for some purpose or purposes. The transportation XML vocabulary was created for the purpose of enabling the transportation office to provide a limousine service for its employees.

17 2. Support Senders & Receivers 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 element I have failed to support the transportation service that my XML vocabulary is supposed to support. The design of an XML vocabulary must take into account the need of data providers to supply the data and the need of data consumers to use the data.

18 3. Keep Focused An XML vocabulary that is too generic will fail. Focus the XML vocabulary to a specific purpose or (small) set of purposes.

19 4. Optional Markup/Data If there is markup/data needed by the data receivers but not the data senders then make it optional. Thus the sender 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 sender 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 element so make that element optional. The transportation office will add it when the travel request document is received.

20 5. Flexible/Extensible Design flexibility and extensibility into the XML vocabulary, but do not try to predict the future.

21 6. Modularize Modularize the XML vocabulary. Create the XML vocabulary as an assembly of building blocks ("data components").

22 7. Component Design Split out markup/data that is optional and specific to the data receivers. One technique, for example, is for the receiver to add the data that is specific to him in an envelope that wraps the sender's data. The envelope topology is one approach to component-based design; many others are possible and should be explored. See example on next slide

23 Envelope Component Design T12:07:00Z home Logan airport T07:00:00 Logan airport home T18:00:00

24 Acknowlegements The following people contributed to this work: –Mike Brenner –Len Bullard –Marcus Carr –Roger Costello –Alan Danziger –James Fuller –Fraser Goffin –Ken Holman –Ken Laskey –Frank Manola –Paul Spencer –Jim Wilson