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

["Jim Wilson" <jim.wilson@kcx.com>]

Roger,

The context for my comments comes from industry standards-setting
activities, concentrated in the chemical and agriculture industries. I
suspect that my comments would apply to similar activities within a
company, but I have little experience with that. Many of my comments are
common sense so take them as potentially worth adding to your list
rather than telling you something you didn't already know.

Best regards,
Jim Wilson
CIDX Chief Architect


> -----Original Message-----
> From: costello@mitre.org 
> 
> 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.

Agree. Some comments:

a. I agree that it is important to get inputs from a diverse set of
people. I also think it is important to do so in a group setting so that
the input can be discussed, other perspectives understood, and consensus
reached.

b. Employ a facilitator who is a business-minded TE. Domain expertise is
not required (and can be an impediment). This person must be comfortable
leading a discussion about process and data (see next comment), must be
adept at hiding the complexities of XML while still exposing the
hierarchical, cardinality, and basic data type aspects of the data
requirements that are intuitive to SMEs.

c. Ultimately data implementations support processes. Sometimes it's
important to agree on processes before discussing the data. Sometimes
discussing data first helps people recognize a process-alignment issue.

d. Don't underestimate the importance of tools, room setup, and roles in
a session. For example, I find TurboXML a more effective schema editor
in a group setting than other XML editors or text editors (my preference
for work on my own). Also, for example, having two projectors--one for
the schema and one for the data dictionary/glossary is very helpful.
With respect to roles, find the best note taker and put them in charge
of the data dictionary/glossary.

e. Implementers appreciate naming and design rules that lead to
consistency and they are willing to compromise on naming and design
preferences to support consistency. The choice between "ProductID",
"ProductId", "ProductIdentifier", "ProductNumber" should be dictated by
naming and design rules, not the person with the strongest preference.

f. Finally, avoid code list maintenance/architecture discussions. The
topic seems so intuitive and inviting that every rookie thinks they have
the solution to the "simple problem". Work in this area continues today
by veterans (eg, UBL and UN/CEFACT). Code list maintenance/architecture
discussions are a time sink and are best left to TE discussions over a
pint of Guinness.


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

See my comment in 1.d. Additionally, I find that demanding precise
terminology and definitions along with encouraging documenting lots of
notes and examples is very helpful in the long run. In particular,
noting distinctions and relationships between concepts is helpful. The
more successful an XML data implementation becomes, the more likely it
is that it will be revisited in the future for extension and application
in other contexts, at which point the value of the notes and examples is
really appreciated.


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

Agree. See note for #5.


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

"...technical expert take into consideration..." I think is the right
role engaged in the right activity. I've experienced all too often teams
that get bogged down in performance speculations (eg, schema too big;
element names too long; nesting too deep; code list values too many
characters; xsd:maxOccurrence='unbounded' not changed to a "reasonable"
value). Often, simple performance tests shatter performance
assumptions--assumptions that if addressed would lead to awkward designs
(from semantic perspective, at least) and almost always waste valuable
team time in discussions. Who cares if a desktop application processes
data in 500 milliseconds vs. 5 milliseconds (with an alternative design)
twice a day? My default perspective is that if performance and bandwidth
are critical concerns, then XML may not be the right syntax for you.
Having said that, there have been occasions where performance really was
an issue that could be addressed by design changes. One other comments
about performance relates to #3. Often I find that a design decision
made for one implementation optimization results in a performance
degradation for another implementation.