Lists Home |
Date Index |
- From: John Martin <John.Martin@ncmail.net>
- To: email@example.com
- Date: Fri, 06 Aug 1999 10:49:41 -0400
Our shop is on a course of "federating" data; that is, identifying
common data elements used across the state, and agreeing on a standard
usage and format for them. Some examples of the first few data elements
we're trying to standardize are: City, State, Zip Code, Date, Race, and
Sex. An example of how we're defining an element is:
Data Element/Attribute Name: Zip Code
Element Definition: As defined by USPS: The address element that
identifies a geographic region or specific location defined by the
postal service within the US.
Valid values: USPS Table
Element Format: 5N
Element Length: 5 Bytes
Element Type: Numeric
The idea then is that in all new programs being created (regardless of
language or platform, in theory), if any of these data elements are
used, this is how it should be used. This, in theory, will promote
interoperability in inter-agency programs.
Needless to say, this is a huge undertaking. Though I'm fairly new to
XML, I have an inkling that if XML becomes a standard for passing data
back and forth, the need for "federating" the data in this way would be
unnecessary. The DTD (and namespaces?) would take care of describing
the data so programs would understand how it's being used? When I've
mentioned this, one of the typical responses I get is, "Then, won't the
XML tags have to be "federated?"
I'd be interested in anyone's thoughts and/or words of wisdom on this
whole idea. Has anyone done this? Or traveled down this road either in
practice or in theory? What was your experience?
org:State of North Carolina;Information Resource Management (IRM)