1 / 24

Rules of Thumb for Creating XML Vocabularies for Workflow Applications

Rules of Thumb for Creating XML Vocabularies for Workflow Applications. February 1, 2009. Contents. Definition of "workflow applications" Case study Lessons learned/rules of thumb Acknowledgements. XML. Rob. Jill. Anthony. Sally. Pete. Workflow Applications.

blue
Télécharger la présentation

Rules of Thumb for Creating XML Vocabularies for Workflow Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rules of Thumb for CreatingXML Vocabulariesfor Workflow Applications February 1, 2009

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

  3. XML Rob Jill Anthony Sally Pete Workflow Applications • In XML-based workflow applications the XML documents are routed, and may be modified at various stops along the route:

  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 <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> "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."

  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. <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> RECEIVED Jan. 28, 2009

  7. Add a Submission Element? • When I created the 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? See example on next slide 

  8. 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>

  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 <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.

  12. No Submission Element • I decided not to include a <Submission-Datetime> element in my XML vocabulary. • The transportation office can create their own XML vocabulary that adds a <Submission-Datetime> 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 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. 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.

  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 <Submission-Datetime> 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 <Transportation-Office-Request> <Submission-Datetime>2009-01-28T12:07:00Z</Submission-Datetime> </Transportation-Office-Request> <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>

  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

More Related