RE: [xml-dev] What makes a data component good for standardizing?

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

The user anticipates you.

It is a negotiation.

len

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: Saturday, January 10, 2009 8:34 AM
To: 'xml-dev@lists.xml.org'
Subject: [xml-dev] What makes a data component good for standardizing?


Hi Folks,

Suppose you set out to create some standard data components. Your goal is to
improve interoperability by creating standardized data components.
Particularly, you want these standardized data components to improve
interoperability between systems that weren't a priori coded to understand
each other's data exchange format (i.e. you want to improve interoperability
with the "unanticipated user").

What makes one data component good, and another bad? 

(By "good" I mean the data component would in fact help improve
interoperability with the unanticipated user. By "bad" I mean the data
component would do little, if anything, to improving interoperability with
the unanticipated user.)

I'll share my initial thoughts. I'd like your feedback on my initial
thoughts, and I'd also like to hear your thoughts.

Note: by "data component" I mean a chunk of markup that can be reused in
multiple XML vocabularies.


MY INITIAL THOUGHTS

I think that some data components would be good to standardize, while others
would not be useful. 

I'll start with two examples of data components would be good to
standardize.

Think about a postal address. It would be a good data component to
standardize. It's a useful data component even if I don't understand the
context in which it's being used. 
 
      For example, suppose some nuclear physicist unexpectedly sends 
      me a document containing data that I have no clue 
      what it means, but embedded in it is a postal address. 
      I may not be able to process all that data about 
      subatomic particles (quarks, neutrinos, etc), but I can 
      pluck out the postal address and store it in my address book. 
 
That's interoperability between unanticipated users, albeit limited.
 
Another example of a useful data component is a business card (vcard).
Again, that's a useful data component that I can immediately utilize, even
if I have no clue what the rest of the document is talking about.
 
These data components are useful independent of their context. I can use the
data components even if I can't use all the stuff that they reside in.
 
Now I'll give an example of a data component which I think would not be
useful to standardize.

Both postal address and vcard gives a person's name (along with other data).
Suppose I decide that I want data components with finer granularity than
postal address or vcard. Would "person name" make a good component for
standardizing?

I think not. A person's name would not be useful independent of context.  
 
      For example, the same nuclear physicist above 
      sends me the same document but containing the
      standardized PersonName data component, about
      a person named "Jim Brown.
      I am PersonName-aware so I am able to pluck out that 
      Jim Brown information, even though I have 
      no clue what the rest of the document says. 
      Have I gained anything? No. It could be Jim Brown 
      the ex-football player or some other person by that name.
      To make sense of the data component I need to
      understand its context. 
 
I propose these two metrics for evaluating the usefulness of data component:
 
    1. The data component must be standardized
       and broadly adopted (see below).
    2. If I can meaningfully use the data component
       without understanding any of the context in 
       which it resides then it is a good data
       component. If I must understand its context
       then it is a bad data component. 
  
Standardizing is good. It enables two parties to understand each other,
i.e., interoperate. 
 
But standardization is not enough. I want more than interoperability between
two parties that have a priori agreed to a data interchange format. I want
interoperability between two parties that haven't a priori agreed to a data
interchange format. I want interoperability between unanticipated parties.
 
So the key is to not only standardize, but standardize the right things.
 

SUMMARY 

We would go a long way toward advancing interoperability of unanticipated
systems if we focused on creating standardized components that are useful
independent of context.

What do you think?
 
/Roger  
_______________________________________________________________________

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