[Summary] Keep business-process-specific data separate?

["Costello, Roger L." <costello@mitre.org>]

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.