Hi Dave,
thanks a lot for this schema. I can sense the enormous amount of design
deliberations behind it. It is a very respectable work.
Please remember that this schema is not an official part of the OMG specification,
but it is what we have used so that we can have a full XML representation of the data that
the OMG PIDS expects. It has some small extensions as to the "type" of data as the
spec only handles HL7 and vCard officially, as well as a few special PID types. We have found
that it works very well for a variety of application areas far beyond healthcare. Also remember that the PIDS
specification lets you ask it what are the properties of any particular trait type, so that
a conformant system can not only tell the client what is supported but something about
what the particular traits "mean".
On Friday 30 April 2004 09:46, David Forslund wrote:
> I've attached an XML schema for the PIDS data model that we use. It is
> completely consistent with the OMG PIDS specification. This entire issue
> of flexible dynamic traits vs rigidly defined traits was discussed in great
> detail during the development of this RFP.
> As a result we agree very well with the Archetype models proposed by
> openEHR
We are still waiting for your promised servers to enable us to test this
schema. Also, please point us to libraries or drivers that we can use in our
applications to hit your servers using the PIDS data model.
All of the libraries and drivers to access it through CORBA are on http://OpenEMed.org,
of course. I've not provided the web services/xml-rpc/rest interfaces yet. This has
not yet been a high priority for me to do, since the existing interfaces provide full
interoperability, high performance, security and standards based.
By the way, the xmlrpc libraries available around make the protocol
transparent to the programming language. The programmer does not even need to
know how the xml formatted data being exchanged looks like. He thinks on the
basis of his programming language.
Perhaps, but I don't understand why you insist on having a username and password
in the arguments. This makes the communication very awkward and not particularly
useful for real secure systems that don't use passwords. In our experience the
security is negotiated completely independent of the call and is enforced on the wire
by the underlying protocol. I would assume such is possible with xml-rpc.
The CORBA solution also means one thinks in terms of their programming language
and, in fact, don't even have to think in terms of XML if they don't want to. (Many people
today think of XML as a programming language).
The protocol is totally transparent to the programming language in the approach of the
OMG PIDS. I see all kinds of work going on trying to figure out how to tear apart an
incoming message (which is also true in HXP, as far as I can tell). We haven't had to deal
with how to tear apart an incoming message for many years. We have many people
using CORBA who have no idea that is what they are doing. They only think of making
calls to objects. EVen with XML-RPC, I have to convert from my programming language
to something else to make the XML-RPC call. If I used XML-RPC, I will be wrapping it
with something that takes care of this problem, too. So in one sense, there is nothing new here,
just something different and with different comfort factors.
It will surely improve acceptance if this is to be found in your protocol.
Can you please point us to similar libraries or drivers which make your
protocol transparent to the programming language? We will highly appreciate
it.
Check out our code base. For example we have in the src/clients/gov/lanl/Web directory
classes which let web applications use our (or any OMG standard) service without having to
know anything about CORBA. I will be adding additional interfaces in this package or a related
one to enable the pure web remote access.
Thanks,
Dave
Regards,
Elpidio
