Re: [xml-dev] [Summary] Should Subject Matter Experts Determine XMLData

["Simon St.Laurent" <simonstl@simonstl.com>]

Costello, Roger L. wrote:
> Should data be designed for specific applications? Or, should data
> design be a matter of documenting a cow path? 

Or, perhaps, we should simply give up on the conceit that 'data design' 
is something where one size genuinely fits more than one.

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

Interesting, but false. Your SMEs have been spending too much time 
thinking about one aspect of book data, probably sales, and have 
forgotten that none of those elements is actually necessary to a book. 
They're only necessary for the expectations of the systems that trade 
books, which is actually a microscopic subset of the information around 
a book.

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

Iterations may be the only part of this story I agree with, and I'd 
suggest that many more than "several" are likely the answer.

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

It only supports 'unanticipated users' so far as they find your schema 
actually fits their needs.  I can't say I'd expect many users to find 
this helpful.

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

That's because you deliberately edited them out by talking with 
so-called experts who actually know almost nothing about how books are 
created, sold, consumed, resold, recycled, interpreted, stored, or even, 
apparently, read.

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

'Cow path' is a phrase that worries me.  I know what it means, but fear 
that it's use doesn't reflect even the wandering cows do, never mind humans.

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

You've basically declined to support 90% of those implementations in any 
event, so I'm not sure that you've proven anything about data 
specification scope.

To be serious, I've spent/wasted the last six years with a database 
supposedly documenting books (and book-like things).  It contains many 
many more fields than the ones you've listed, but the viewpoint is 
basically the same - except that the ISBN is mandatory only later in the 
process.

At this point, I'm giving up on that gigantic data store, except to the 
extent my employer requires me to feed it data, and rolling my own. (And 
eventually sharing it, whereupon I know I'll get to change everything 
again.)

'Book' becomes a title for one phase of a  project's lifespan, and that 
may not even end up being the term - the more generic 'product' might be 
a wiser choice.  The earlier phases have rich information all their own 
that aren't normally captured anywhere in our systems, and even after a 
book is published there's vastly more worth tracking than the minimal 
'book' you describe.

Not only that, it's becoming clearer and clearer as we talk about this 
that even the shared components, notably Title and its subcomponents, 
have very different meanings and priorities for different participants 
in the conversation, based on what they actually need to do with them.

I don't think your process works well except in cases where a minimal 
core is usefully shared - which is questionable here, though not 
entirely useless - or in cases where process is so rigidly defined that 
any deviation from the prescribed path is a sign of grave failure.

I know that when XML started out we all hoped that data standards could 
be assembled quickly and all sorts of systems automated.  That vision 
was only a vision.  XML addressed one tiny if thorny bit of data 
exchange and processing.  The rest remains as complex, intricate, and 
mind-bending as it ever was.  And 'experts' remain as limited as they 
were before.

Thanks,
Simon St.Laurent
XML retiree