MHonArc v2.4.5 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Naming Conventions
Title: RE: [emergency] Naming
Conventions
Here. Here. Not that I think the Pharmceutical Industry is a
great example to follow, just that the methodology makes sense.
Ciao,
Rex
Another path through this mess is what CDISC has
done. The FDA published a set of rules for submitting drug
information electronically so a pharma could get its hot drug
approved. CDISC [clinical data information standard consortium]
was formed from vendors, pharma companies and others to jointly
develop an implementation standard using xml. They have defined
the tree structure with controlled names. NCI used common data
elements (CDEs that I spoke about) to handle the data element meta
data, the instances of data within a specific node of the tree.
The fact that there were real world objects [forms and data on them]
enabled this project to move forward pretty quickly. I have been
involved in too many data element definition project for DOD in the
past that tried to do it all and failed miserably because real world
apps and their users were not involved.
John
-----Original
Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: Friday, April 18, 2003 12:36 PM
To: 'Rex Brooks'
Cc: emergency@lists.oasis-open.org
Subject: RE: [emergency] Naming Conventions
Got it, Rex. The usual meta-meta problem:
do a data design a la abstract interface
or create a vocabulary. I like the VRML solution
to that: do both with the
encodings and vocabularies as optional features.
It's more work but one
can nail down the semantics and give the user
community a chance to
converge at the level of efficiency most appropriate
to the local contracting
situation. When volunteer groups sit down to
create specs and standards,
they should keep in mind the problem for the actual
industry of changing
horses. We're glad to see the work being
done by OASIS in public safety,
but until it shows up in an RFP, it's just
nice-to-have, Sounds Good Maybe Later,
kind of work. DOJ can't drive it down from the
top without funding it too. And
technical standards that don't account for medium
constraints don't have a
snowball's chance anyway. Thus, we use the
RFP to guide us and cost
accordingly.
I note reading through the JusticeXML dictionary that
they have wisely left
open most aspects of the data definition (eg, loose
types, loose occurrence
constraints, etc) and stayed mainly to a labeled
tree. Much easier to live
with that way.
len