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

["Len" <cbullard@hiwaay.net>]

++1

Too often I get schemas with serious scoping problems.  They try to do too
much and don't set the boundaries.   We talk about use cases when we should
be talking about job-at-hand.   Instead of being explicit about the actual
physical real actors in the transaction, they create a model of an actor and
it is loose enough to take in so many actors that the job scope increases in
unanticipated ways.

Here is an example:  

"I want you to support HL7."

"Which messages?"

"I don't care.  To pass certification, you have to support HL7."

"Can you give me a list of the partners you will be exchanging these
messages with?"

"I don't want the system to restrict that.  You have to support HL7."

The old term for this is "boiling the ocean".

len

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent: Saturday, October 04, 2008 8:12 PM
To: Kurt Cagle
Cc: Costello, Roger L.; xml-dev@lists.xml.org
Subject: Re: [xml-dev] [Summary] Should Subject Matter Experts Determine XML
Data Implementations?

Kurt Cagle wrote:
> In my experience designing ontologies for different groups, one thing 
> that I find keeps cropping up is that SMEs tend to create data 
> structures that most closely approximate their understanding of a 
> subject, not necessarily that provides the most optimal representation 
> of that data model. Certainly SMEs should be involved at all stages of 
> the ontology process, but I've also found that if left up to the SME 
> alone, the models are often awkward to implement, tend to be 
> overspecified, and as often as not contain sometimes bizarre assumptions 
> that can significantly limit these models when translated into a 
> computing environment.

I have to agree with Kurt.  Subject matter experts may well be experts 
at the subject, but making 'expert' data models work is not always a 
good idea.  I'd probably go further, though.

Frankly, when building data models, I'd much rather have a mix of skill 
levels and perspectives involved.  Different participants have different 
views on the data, but there's often more than just views on the same 
data model - there are often different internalized data models.

Combining those different models with data structures requires more than 
just careful data design.  I'd argue it involves programming, 
transformations at minimum, that ensure that the data presented meets 
local expectations.  That's never easy, but I don't think it's avoidable.

It's been a long time since I've been involved with this in an XML 
context (though I'm starting to work with it in a database context 
again), so I'm a bit cautious about saying this.  Nonetheless, it seems 
so obviously true to me that I might as well.

Thanks,
Simon St.Laurent
XML retiree

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php