Re: [xml-dev] Rules of Thumb for Creating XML Vocabularies for Workflow

[Fraser Goffin <goffinf@googlemail.com>]

Roger, slightly picky but ...

you use terms like 'producers' and 'consumers', and also intersperse
'receivers' (see point 4).

Whilst its mostly obvious who you are referring to it would probably
be clearer if you stuck to one term for each. In the world of
services, consumers are often regarded as the 'users' of services
(i.e. 'senders'), whist 'providers' represent the service
implementation ('receivers'). So some of us who are used to this
terminology have a slight mind twist to follow yours. There is no
'official' or right/wrong, just an observation.

On something slightly different. I guess deliberately some of your
'rules of thumb' are very general / non specific, like point 5 for
example. In earlier posts by you, you were considering the
unanticipated [service] user, so I'm not sure if you are still
following that theme here. But ultimately the success of an exchange
relies on the agreed semantics of the participating parties, so whilst
some 'senders' may include 'extra' data, thats not much use unless a
'receiver' either knows what to do with it (in that case its not
really unexpected) or decides to implement a 'must ignore
(retain/discard)' policy for unexpected data (this can have some
serious business/legal ramifications in some cases as can 'rogue'
service use itself). I am assuming that your point 4 is concerned with
a 'receiver' carrying out some internal data enrichment which I
suppose could be as simple as adding defaults for any optional data
not received and as complex as ... well as you like. In the later case
it may not form part of the service [data] contract at all, in which
case it is part of 'data on the inside' as Pat Helland would probably
describe it so isn't part of you exposed vocabulary.

Regards

Fraser.


2009/1/31 Costello, Roger L. <costello@mitre.org>:
>
> Hi Folks,
>
> I changed the subject line on this email thread to reflect its tighter focus.
>
> I've incorporated the latest comments. Please let me know of any changes you recommend. /Roger
>
>
> DEFINITION
>
> The list below contains guidelines for creating XML vocabularies for workflow applications. In XML-based workflow applications the XML documents are routed, and may be modified at various stops along the route.
>
>
> RULES OF THUMB FOR CREATING XML VOCABULARIES FOR WORKFLOW APPLICATIONS
>
> 1. An XML vocabulary does not exist in a vacuum. It exists for some purpose or purposes.
>
> 2. An XML vocabulary must support the data needs of both the data producers and the data consumers.
>
> 3. An XML vocabulary that is too generic will fail. Focus the XML vocabulary to a specific purpose or (small) set of purposes.
>
> 4. If there is markup (data) needed by the consumers but not the producers then make it optional. Thus the producers can omit the optional markup while the receivers can add it.
>
> 5. Design flexibility and extensibility into the XML vocabulary, but do not try to predict the future.
>
> 6. Modularize the XML vocabulary. Create the XML vocabulary as an assembly of building blocks ("data components").
>
> 7. Split out markup (data) that is optional and specific to the consumers. One technique, for example, is for the consumer to add the data that is specific to him in an envelope that wraps the producer's data. The envelope topology is one approach to component-based design; many others are possible and should be explored.
> _______________________________________________________________________
>
> 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
>
>