Costello, Roger L. wrote:

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

Is that not a given? Do you mean to convey the fact that the quality of 
an XML vocabulary may be judged by its fitness for purpose? I'd agree 
with that...

> 2. An XML vocabulary must support the data needs of both the data
> producers and the data consumers.

Data producers are irrelevant - they have no needs. There are only the 
needs of data consumers. Sometimes a producer may also be a consumer, 
but they're distinct roles and should not be conflated.

> 3. An XML vocabulary that is too generic will fail. Focus the XML
> vocabulary to a specific purpose or (small) set of purposes.

The single most critical factor, in my opinion.

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

You're conflating producers and consumers again. The original producer 
has a clear set of requirements for their downstream recipient. That 
recipient also has a clear set of requirements - augment the data and 
feed it to another process. It doesn't automatically follow that the 
original producer must have some knowledge about how the recipient 
intends to augment the data - ideally they wouldn't have a clue. If the 
recipient changes their requirements, should the changes really flow 
back to the original producer? You'd hope not... see point 3.

> 5. Design flexibility and extensibility into the XML vocabulary, but
> do not try to predict the future.

Sounds good...

> 6. Modularize the XML vocabulary. Create the XML vocabulary as an
> assembly of building blocks ("data components").

As long as the assembly and understanding of the building blocks doesn't 
cause more overhead than what it's trying to solve. Sometimes for a 
well-defined system, it's just as easy to diff the schemas for the 
various processes as it is to manage the structures.

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

I think that there are too many possibilities to bother trying to 
generalize. My guide would be to store the additional data in a way that 
makes it most fit for purpose for the immediate downstream recipient(s), 
but that doesn't say anything very helpful either.


Marcus

_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php