[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Rules of Thumb for Creating XML Vocabularies for Workflow Applicatio

  • From: Marcus Carr <mcarr@a...>
  • To: "Costello, Roger L." <costello@m...>
  • Date: Mon, 02 Feb 2009 10:59:12 +1100

Re: Rules of Thumb for Creating XML Vocabularies for Workflow Applicatio
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.