ADL to XML Schema

2005-03-09 Thread Sam Heard
David W. Forslund

Good to see you sniffing around! The key issue for us in ADL is that 
Eiffel is not UNICODE compliant. There will be a number of Java parsers 
soon, and I hope a JAVA archetype editor.

I am interested in what you can do with Schematron as well as another 
implementation routekeep me up to speed.

Cheers, Sam
 I've been looking at schematron for doing the equivalent of archetype in
 a more general situation, particularly since there as been no ADL parser
 available in Java.   Schematron seems to be reasonably popular for
 enforcing rules for XML data structures and there is a variety of software
 available for using it.
 
 Dave
 On Tue, March 8, 2005 4:28 am, Gavin Brelstaff said:
 
Rahil Qamar wrote:


Hi Alfonso

I can answer one of your questions for certain and am not very sure
about another one.

Alfonso Mata wrote:


- Is it possible to obtain a XML-Schema based on 13606 from an ADL
file?



You can obtain an XML representation of the ADL Archetype from the
Archetype Editor but not an XML Schema. Atleast not at the moment.
However Im trying to write out a schema based on the UML Archetype
Object Model. Its not proving to be an easy task is all I can say ! I've
done one version of  the schema but its far from perfect to generate a
sensible XML. If you are interested in doing some work on this we could
collaborate.

There are some less heavy ways of doing XML rule checking that
avoid most of the irrational intricacies of the W3C Schema.
Did you ever explore
Jim Clark's RelaxNG for schema validation of XML structures,
and
Schematron for rules involving Co-occurance relationships.

That might be a way to go.


--
Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia
Loc. Pixina Manna Edificio 1,
C.P. n.25, 09010 Pula (CA) Italy.
Email: gjb at crs4.it Phone:+39.070.9250.312 Fax:+39.070.9250.216

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

 
 
 
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



archetypes and class constraints

2005-03-09 Thread Gerard Freriks
The beauty of OpenEHR (and CEN/TC251 EN 13606) is the fact that we have 
a reference document model that because of its stability help store and 
retrieve persistent documents over long periods of time.

Being able to change the reference document model will create problems 
by to much divergence.

Gerard

--  private --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 08 Mar 2005, at 01:58, Carl Mattocks wrote:


 I vote for the pragmatic approach when we don't control the reference 
 model

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 633 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050309/18564377/attachment.bin


EntityNameParts

2005-03-09 Thread Bert Verhees
I will come back to the answers I got about II later.
Thanks for this.

I have another question: about EntityNamePart in the CEN-standard.

There seems to be no way to tell if a certain namepart actually are 
name-initials.

f.e.
Sometimes people often have more firstnames.

Often they have a name that is used for casual contacts, and they have names 
which are in their passport, their official firstnames, which are often long 
names.

Often, these long names are only known by initials

Now I am extracting data from a local GP-system, and there is stored the 
shortname (f.e. Johnny) and the initials J.B. 
His friends call him Johnny B. Good. The second name in that system is only 
known by Initial. I have to deal with that.

Because I want to present as much information as is possible in the standard, 
and I want to present the shortname (GIVEN NAME=Johnny), FAMILY NAME=Good, 
and because I want to give as much information as possible, because this can 
be important to identify a person, I want to add an extra entityNamePart: 
J.B.
And now I am looking for a namepartType or namePartQualifier for initials.

Someone have an idea?

Thanks

-- 
Met vriendelijke groet
Bert Verhees
ROSA Software
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



Problem with Datatype: Instance Identifier (II)

2005-03-09 Thread Thomas Beale
Jan Dockx wrote:

 There is such a system: DNS. Why in heavens name did we invent a new one?

DNS is great. In fact, I would suggest that DNS has more chance of 
including more organisations (represented by their domain names) than 
ISO OIDs. But...what if a hospital changes domain name, but is still the 
same hospital? DNS does not have identifying information other than the 
domain name administrator details (what whois returns); is this enough? 
In any case, DNS only works for organisations and sometimes pieces of 
organisations. But how do we want to identify a prescription for 
example, or a lab result? One way is with an OID; another way is 
domain_name+lab_result_id. I think the latter is much more realistic 
today, even if the former seems more theoretically satisfying (even if 
it completely unreadable to humans;-)

- thomas

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



EntityNameParts

2005-03-09 Thread USM Bish
On Wed, Mar 09, 2005 at 10:29:45AM +0100, Bert Verhees wrote:
 I will come back to the answers I got about II later.
 Thanks for this.
 
 I have another question: about EntityNamePart in the CEN-standard.
 
 There seems to be no way to tell if a certain namepart actually are 
 name-initials.
 
 f.e.
 Sometimes people often have more firstnames.
 
 Often they have a name that is used for casual contacts, and they have names 
 which are in their passport, their official firstnames, which are often long 
 names.
 
 Often, these long names are only known by initials
 
 Now I am extracting data from a local GP-system, and there is stored the 
 shortname (f.e. Johnny) and the initials J.B. 
 His friends call him Johnny B. Good. The second name in that system is only 
 known by Initial. I have to deal with that.
 
 Because I want to present as much information as is possible in the standard, 
 and I want to present the shortname (GIVEN NAME=Johnny), FAMILY NAME=Good, 
 and because I want to give as much information as possible, because this can 
 be important to identify a person, I want to add an extra entityNamePart: 
 J.B.
 And now I am looking for a namepartType or namePartQualifier for initials.
 
 Someone have an idea?


Naming conventions  and methods  of writing  vary all  over the
world. It may be difficult finding a common rule fitting all. 

I thought all that the CEN/TC251 specified for Class:EntityName
was merely 'a  character string' (or several  entity name parts
in sequence). This is applicable  for a person, organisation or
even place  or an object. 'EntityNamePart'  would therefore  be
sub-components of the above.

But how  do you  define the  sub-componets, as  far as  name is
concerned ? 

There are  no fixed patterns  for names or  naming conventions.
There are many  societies where there are no  'Family' names at
all.  Some have  Tribe names  in  lieu, some  with father's  or
village name  as 'names' somewhere  wedged in the  name string.
Some with just  unique names with nothing else. To  add to this
confusion you would  then have to find  sub-components for nick
names and aliases.

Bert, like your  query regarding short-name and  initials, I am
also curious in knowing how these name issues are planned to be
tackled ... Are there any thoughts in this direction ? Or is it
better to leave EntityName simply  as a 'character string' with
no futher qualifications.

Bish


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



Problem with Datatype: Instance Identifier (II)

2005-03-09 Thread Bert Verhees
Thomas Beale wrote:

 Bert Verhees wrote:


 Now I must tell them they have to recognize the InsuranceNumbere 
 from  the OID which points to InsuranceCompany, somewhere??.

 There has to be a service on the Internet where one can translate 
 OID's to friendly names, something like DNS for IP. Or else, this 
 system cannot work


 right - this is the problem with OIDs - they only really work if they 
 are in global, ubiquitous use. I don't see this happening.


Another problem with OID, not everyone may agree, is that they contain 
no meta-information, betters said, the problem is with II, it offers no 
property for meta-information meant for automated processing. You can 
never find out what kind of number you are processing.

I wonder, what does CEN say about this, about your, in their eyes, must 
be, controversial meaning?

What do they say about OID at all?
They have to believe in the system, they are advising the Dutch 
government to start implementing CEN-standards next year.
And I am already implementing it, but in a special way.

regards
Bert Verhees


 - thomas

 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org



MCAFEE E-MAIL SCAN ALERT!~RE: ADL TO XML SCHEMA

2005-03-09 Thread Linden H van der (MI)
 of the W3C Schema.
 Did you ever explore
 Jim Clark's RelaxNG for schema validation of XML structures,
 and
 Schematron for rules involving Co-occurance relationships.
 
 That might be a way to go.
 
 
 --
 Gavin Brelstaff - BioMedical Area, CRS4 in Sardinia
 Loc. Pixina Manna Edificio 1,
 C.P. n.25, 09010 Pula (CA) Italy.
 Email: gjb at crs4.it Phone:+39.070.9250.312 Fax:+39.070.9250.216
 
 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org
 
 
 
 
 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org
 
  
  
  
   File: openEHR-EHR-OBSERVATION.blood_pressure.v1.adlFile:
 BloodPressure.xml  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050309/21566a5b/attachment.html