[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Keep business-process-specific data separate?

• From: Frank Manola <fmanola@a...>
• To: "Costello, Roger L." <costello@m...>
• Date: Wed, 28 Jan 2009 13:37:45 -0500

On Jan 28, 2009, at 11:11 AM, Costello, Roger L. wrote:

>
> Hi Folks,
>
> Suppose I create an XML vocabulary for a "Transportation Task  
> Request." Here's an example:
>
> 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 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>
>
> I create this document then walk it over to my 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.
>
>
> QUESTION
>
> When I create my Transportation Task Request XML vocabulary, should  
> it include a <Submission-Datetime> element? Thus, when I create my  
> instance document, I 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  
> fill in the element.
>
> 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 really relevant to my  
> objective. The <Submission-Datetime> element only comes into play  
> when I hand my travel request document to the person at the travel  
> office. That is, the <Submission-Datetime> element is only relevant  
> in this particular business process.
>
> The <Submission-Datetime> element is business process-specific data.
>
>
> AVOID BUSINESS-PROCESS-SPECIFIC DATA
>
> I think that it's bad to put business-process-specific data with my  
> XML vocabulary.
>
> Do you agree?

Roger--

A few points:

1.  You seem to have in mind that expressing a transportation task you  
want accomplished is separate from a business process, rather than  
being part of one (the process of getting transportation, or at least  
that part of it that you accomplish via this request).  It seems to me  
you need to explore this assumption a bit.  I can imagine that some  
separation of this sort might be appropriate in some cases, but it's  
not clear this is a very good example.  It seems to me your request  
here is a part of a communication with some other agent, and both  
*your* requirements and *their* requirements need to be considered is  
establishing the vocabulary.  For example, they may want to have the  
submission-datetime as part of the request in order to validate it  
(you may be requesting transportation after the time of request  
submission, in which case either there's an error or you're requesting  
an impossibility).

2.  "Thus, when I create my instance document, I include an empty  
<Submission-Datetime> element"  Why?  This isn't a relational  
database, it's an XML document.  Just because the <Submission- 
Datetime> element is part of the vocabulary doesn't mean it has to be  
included in every document created using that vocabulary.  Why not let  
the travel office add it?

>
>
> 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 travel  
> office, I also drop a copy off at human resources. The first thing  
> the human resources 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.

3.  Why do you also drop off a copy at human resources?  If it's a  
company requirement that you do that for every travel request, isn't  
that part of the *same* business process, rather than a different one?


>
>
> 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.
>
> Do you agree?

4.  I'm not sure I understand the relationship between the vocabulary  
and the contexts in which it can be used that you're assuming here.   
Surely if I have a standard vocabulary for expressing, say, dates  
relevant to the creation and usage of some document, I could use it in  
all sorts of business processes (including this one), rather than  
having to invent different vocabulary for each process.  Why doesn't  
this apply to any vocabulary?  I shouldn't have to reinvent vocabulary  
for expressing the starting and ending points of trips for that  
matter.  What's the objection to mixing elements from different  
vocabularies?

5.  It seems to me this whole use case needs a little more analysis.

--Frank

>
>
>
> WHERE TO PUT THE BUSINESS-PROCESS-SPECIFIC DATA
>
> If I don't put the business-process-specific data with my  
> Transportation Task Request data, where do I put it?
>
>
> /Roger
>

• References:
  • Keep business-process-specific data separate?
    • From: "Costello, Roger L." <costello@m...>