> ... should also be business as usual; interview, map data flows,
> model the data domain; abstract / normalize, validate the design with
> the SME and other users; iterate again until you have it close enough
> for a prototype then do the same thing all over again until your
> prototype has grown up into a real application.  The fact that you're
> using XML should not change the way turn requirements into an logical
> architecture. 

Should data be designed for specific applications? Or, should data
design be a matter of documenting a cow path? 

I understand best when I see specific, concrete examples, so let me
provide one. 

Suppose I interview several Book SMEs. They tell me that a Book is
comprised of a Title, Author, Date, ISBN, and Publisher.

I document this data and the relationship (parent-child relationship
between Book and Title, Author, Date, ISBN, Publisher) in a Book Data
Specification.

The Book Data Specification is handed off to a techie who then creates
an XML Schema implementation and several sample XML instances.

There may be several iterations to get any confusion cleared up.

I end up with an XML Schema that is independent of any specific
application. Thus, it supports the unanticipated user.

I don't see data flows, application architecture diagrams, or business
processes entering into the picture at all.

It seems to be simply a matter of identifying the data cow path,
documenting it, and implementing it with an XML Schema. 

What and how applications use the resulting XML instances is outside
the scope of the Data Specification - XML Schema Implementation
activity.

No?

/Roger