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

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

Costello, Roger L. wrote:
> Hi Folks,
> 
> Thank you very much for your excellent comments.
> 
> Below is a summary of what I've learned. What would you add to this
> list? What would you change?

This is definitely heading in a better direction.

> 1. It is important to get inputs from a diverse set of people when
> creating a Data Specification and when evaluating an implementation
> (e.g. XML Schema). Different people have different perspectives on the
> information. Never assume that any one person has the whole picture.
> Get inputs from Subject Matter Experts (SMEs), technology experts
> (TEs), users of applications that will use the data, and business
> people. 

You should also be prepared for interruptions and exceptions during and 
after the data design process.

> 2. Be careful of loose, ambiguous terminology. The Data Specification
> must provide clear, unambiguous definitions of the data.

There isn't any such thing for interesting cases, but...

> 3. One or more implementations are derived from a Data Specification.
> An implementation may or may not be a 1:1 mapping of the Data
> Specification. 
> 
> For example, a Data Specification may describe the data in a
> traditional parent-child format, whereas the implementation may be an
> RDF document.
> 
> A Data Specification implementation may be incorporated into a broader
> activity which requires a generalization of the data. For example, Book
> data that is specified in a Book Data Specification may be incorporated
> into a larger multimedia interchange format, perhaps requiring "Book"
> to be generalized to "Product." 

This is a nice bit of flexibility.

> 4. If there is not a 1:1 correspondence between an implementation and
> the Data Specification, then there must be a way to map between the
> implementation and the Data Specification. This is important for
> traceability. 

That mapping may only flow in one direction.  I'm not sure that'll make 
you happy, but it's not an unusual situation.

> 5. When implementing a Data Specification, a technical expert must take
> into consideration the kinds of processing that applications are
> expected to perform on the data. Certain data designs may make
> processing horribly inefficient, while other designs can make
> processing very efficient.  For example, below is a snippet of two data
> designs of a grape vineyard. There are Pickers on the vineyard:
> 
> DATA DESIGN #1
> 
> <Lot id="1">
>       <ripe-grapes>4</ripe-grapes>
>       <Picker id="John">
>             <metabolism>2</metabolism>
>             <grape-wealth>20</grape-wealth>
>       </Picker>
> </Lot>
> <Lot id="2">
>       <ripe-grapes>3</ripe-grapes>
> </Lot>
> 
> DATA DESIGN #2
> 
> <Lot id="1">
>       <ripe-grapes>4</ripe-grapes>
> </Lot>
> <Lot id="2">
>       <ripe-grapes>3</ripe-grapes>
> </Lot>
> <Picker id="John" locatedOn="1">
>       <metabolism>2</metabolism>
>       <grape-wealth>20</grape-wealth>
> </Picker>
> 
> If the primary processing activity is to *move* the Pickers from Lot to
> Lot, then Design #2 is more efficient because moving a Picker simply
> involves changing the locatedOn attribute.
> 
> If the primary processing activity is to *search* for Pickers on a Lot
> then Design #1 is more efficient because finding the Pickers on a Lot
> is simply a matter of selecting the Lot and then looking for child
> Picker elements.
> 
> A technical expert must take into consideration the types of processing
> that will be done on the data and optimize the data design for that
> processing.

This is a nice example at the markup level, but I'm not sure it needs to 
be in the data design level.  I suspect that these kinds of cases will 
frequently be addressed with simple(ish) transformations of various 
kinds, and that the harder (more important) questions are in the data 
design itself.

Thanks,
Simon St.Laurent
XML retiree