RE: [xml-dev] RE: Keep business-process-specific data separate?

["Paul Spencer" <xml-dev-list@boynings.co.uk>]

Roger,

No, 7 & 8 don't really capture my point. The envelope concept is directly
analogous to the postal service. I can post a letter to my aunt and an
application for insurance to someone else. The process on receipt of these
is different. However, the process of delivery is the same, so the envelope
is the same. In this case, delivery address, sender address and postage due.
The delivery process itself adds data - cancelling the stamp on the
pre-existing envelope. In your example, the added data is the timestamp.

Regards

Paul

> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: 30 January 2009 13:33
> To: 'xml-dev@lists.xml.org'
> Subject: [xml-dev] RE: Keep business-process-specific data separate?
>
>
>
> 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
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>