RE: Keep business-process-specific data separate?

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

Hi Folks,

Thanks for the new insights Jim, Frank, and Paul. Great!

I have revised the list of lessons learned (below). 

Paul, do bullets 7 and 8 capture your point? 

Jim, does bullet 6 capture your point?

Marcus, I am still assimilating your recent message.

Here are the revised lessons learned:

1. An XML vocabulary does not exist in a vacuum. It exists for some purpose or purposes.

2. If an XML vocabulary does not provide the data needed for the purpose for which it was created then it is not useful.

3. "Business-process-specific data versus business-process-independent data" is a false distinction. There is only kind of data: data for some  purpose or purposes, and there is only one kind of XML vocabulary: vocabulary that supports a purpose or purposes.

4. An XML vocabulary must support the data needs of both the data producers and the data receivers.

5. If there is markup (data) needed by the receivers but not the producers then make it optional. Thus the producers can omit the optional markup while the receivers can add it.

6. Distinguish between the XML vocabulary you create versus the XML vocabulary that is actually used in practice: when creating the XML vocabulary, identify the optional markup (data) as described above. Recognize, however, that the XML vocabulary may be used in unforeseen contexts that require markup (data) above and beyond the provided by your XML vocabulary. Design your XML vocabulary to support these unforeseen use cases.

7. Modularize the XML vocabulary: the XML vocabulary should be created as an assembly of building blocks ("data components"). This is particularly useful where the XML vocabulary is used for multiple purposes, e.g. "For purpose #1 I need data components A, B, C; for purpose #2 I need data components B, C, D." 

8. It may be useful to split out markup (data) that is optional and specific to the receivers. One technique, for example, is for the recipient of the data to wrap the data he receives in an envelope along with the data that is specific to him. The envelope topology is one approach to component design, many others are possible and should be explored.


Do you agree with these revised lessons?

/Roger