Re: RE: [xml-dev] [Summary] Should Subject Matter Experts DetermineXML D

[Marcus Carr <mcarr@allette.com.au>]

Costello, Roger L. wrote:

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

For what purpose does this specification exist? If it's intended to be a 
model for the SMEs to enter Book Data, it's a bad idea because there are 
too many weak spots. It would be easy to put a typo in the ISBN, so a 
clever Implementation Expert (?) might suggest that the SME enters the 
ISBN and the system generates the rest of the data by querying some 
external source.

So maybe it's the specification for the SMEs to view Book Data? It's 
still a bad idea. Is this the only view of this data? What if it's also 
going to be subsetted for particular publishers, so will have the 
Publisher data removed? What if that's all that the SMEs need to 
approve, but accessibility guidelines dictate that the data be augmented 
in some way for delivery?

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

No, you end up with a schema that burdens all of the players with the 
crap of the others. Schemas are a poor mechanism for documenting 
requirements - they can be okay if there's a one-to-one mapping and the 
data looks the same all the way through the system, but otherwise 
they're pretty lame. You might consider defining a schema for the SMEs 
interface and another for each of the various uses of the data and then 
tie them together with requirements, but the schema mechanism itself 
isn't adding a whole lot of value to the definition of the system. The 
crucial factor is the information flow through the system, not whether a 
point-in-time validation will succeed.

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

You *can't* see data flows etc. entering the picture, because they break 
the schema. Either that, or you allow everything and try to somehow 
impose the semantics that you intended at a particular point, since you 
didn't formalize them in the schema.

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

It's outside the scope if you just want to create data and validate it. 
It's not if the intention is to deliver a system whereby a user enters 
the Book information into an application designed to minimize errors and 
repurpose the data to accommodate an as yet undefined set of outputs. 
Validation is so nineties... :-)


Marcus Carr