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

[Marcus Carr <mcarr@allette.com.au>]

Costello, Roger L. wrote:

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

For the sake of obtaining transportation, it seems to me that there are 
numerous problems with the structure that you've designed, with quite a 
few of them related to business processes. This is information that's 
going to be given to Joe, the driver, right? If so:

a) whether you think you're departing or returning doesn't matter a whit 
to Joe. They're two separate transportation requests for two different 
dates. Possible reasons for bundling them together might be that the 
company only agrees to take you to the airport if you agree to return. 
What if the wife drops you off for your departure? Are you able to only 
have a return? Who cares? Not Joe...

b) only a starting point and a finishing point? Joe's got a schedule to 
keep, so if you tell him you just want to pop into the office on the way 
home, he's going to be pissed. He wants to plan his day, but you might 
not be giving him enough information.

c) does your datetime relate to the time you need to be at your 
destination or the time you wish to be picked up? Either way, you're 
going to get in the car and start telling Joe that you've got to be 
across town in 12 minutes, because again, you didn't provide him with 
the data he needs. He needs to know when you need to be picked up and 
when you need to be at your destination. If you give him that in 
advance, he can evaluate the likelihood of success, using his domain 
expertise.

d) you do need a submission datetime, so Joe can do the evaluation 
outlined above. If you give him unrealistic times with no chance for him 
to tell you that, it's your problem - if you give him a weeks notice and 
he doesn't respond, it's his.

<Transportation-Request>
     <SubmissionDatetime>2009-01-22T06:15:00</SubmissionDatetime>
     <Request>
         <Pickup>
             <Location>home</Starting-Point>
             <Datetime>2009-01-29T07:00:00</Datetime>
         </Pickup>
         <To>
             <Location>Mimi's place</Starting-Point>
             <Datetime>2009-01-29T08:00:00</Datetime>
         </To>
         <To>
             <Location>Logan Airport</Starting-Point>
             <Datetime>2009-01-29T09:00:00</Datetime>
         </To>
     </Request>
     <Request>
         <Pickup>
             <Location>Logan Airport</Starting-Point>
             <Datetime>2009-01-31T19:00:00</Datetime>
         </Pickup>
         <To>
             <Location>home</Starting-Point>
         </To>
     </Request>
</Transportation-Request>

Some business process specific data certainly does belong in the 
structure - it's necessary for Joe to do his job. Ask Joe which version 
he prefers...


Marcus