RE: [xml-dev] [Summary] Should Subject Matter Experts Determine XML Data

["Costello, Roger L." <costello@mitre.org>]

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?

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. 

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

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

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. 

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.

/Roger