from:"A Verhees"

On 15-04-15 23:11, Thomas Beale wrote:
 On 15/04/2015 17:28, Bert Verhees wrote:
 On 15-04-15 17:19, Dmitry Baranov wrote:
 Sorry Bert ) I had to explain that Oracle 11 is a business 
 requirement, not a hardware limitation.

 Just do it, and then it should run fine, although you have to 
 change the
 XML-Schemas (a bit) before registering them to Oracle. I already
 explained to you before what and why.
 I remember your advise but not sure that changing all the sequences 
 to choices is a right way for many reasons. And I'm almost sure that 
 it's an Oracle bug since other XSD validation tools (visual studio, 
 netbeans and eclipse) say that my instance files are all OK and 
 conform to XML schema.

 You are right it is a messy solution, but if you use sequence, like 
 it is defined in the XML Schema, you have to take care that all the 
 nodes in your XML are in the right/defined order.
 I think this is hard to achieve when XML-files are created in 
 production, but of course, you can arrange that as an alternative.

 I think it is a stupid rule in the XML-Schema standard.

 I just hit this in doing the AOM2 schema. It's a completely senseless 
 rule, clearly a hangover from 'document' thinking - nothing to do with 
 'data' thinking.  I ended up replacing sequence with.

 xs:choice maxOccurs=unbounded

It is a poor man's choice, because of the side-effects.
The choice-constraint makes the engine ignore the minOccurs/maxOccurs 
constraints in the elements under the choice element.


 I have to say, XML-schema based data looks extremely unattractive as a 
 basis for anything except data exchange. I wouldn't try to implement 
 anything important inside a system with it, you are too compromised in 
 too many ways.

It is also used, as I wrote yesterday, to tell an XML-database how, in a 
specific namespace, the data are arranged, in that way the database can 
auto-create indexes, etc.
There is no other way to communicate the structure of XML-documents, and 
even if we found another way, or invented it ourselves, we still would 
need a broad acceptation.

I never heard that there is any work going on in the committees, because 
XML Schema 1.1 is almost 15 years old. I believe it is considered finished.

If that is true, it is very sad.

Bert

OpenEHR and Oracle XML DB problems

On 16-04-15 09:06, Dmitry Baranov wrote:
Hi Bert,

I give up. The problem appears in 12c as well.
And people agree that it is an Oracle bug.
https://community.oracle.com/message/13008017

You should always follow the standard in your analyses, before you
declare one product buggy and another not.
I see in that message that there was a patch recommended, did you try
that? Always use the latest patch level.
Dmitry, if you read the post carefully, not people, but one person says,
it *appears* to be a bug
He has to escalate it to engineering, and if it is a confirmed bug, is
something you must wait for
He says he can reproduce it, this means he used your files.

I checked them also, they validate right in Oxygen.

Oracle in different versions stumbling over your used OpenEHR XML Schema
with your XML-instances?
That is possible. There is a bug in a particular use of your schema.

I am stressing to this because I am posting all the time Compositions in
Oracle 12c, and all kind of other XML-instances from several namespaces.
No problem at all.

But I have things structured in another way. For example, when I post a
Composition, the XML-instance starts with the Document-element called
Composition. This is allowed because I have an xs:element COMPOSITION on
top level in the XML-Schema (xs:element name=COMPOSITION
type=COMPOSITION/). I noticed in a glance that you have that too, and
it is logical that you have, because you flattened the same XML Schema's
as I did.
When you use that, you have to store your audit and version information
elsewhere.

When I look at your XML Schema and instance, just a quick glance, then I
see that you have xs:element name=version type=VERSION/ at top
level, and derived from that Original Version, which has as
child-element data of type xs:anyType. I would not do that, because you
throw away any optimization. Oracle can't do anything with this.
You could at least have it to be Locatable, because data in version are
always of type Locatable.
You could even have a original-version of type composition, and one of
type party, this would help optimization even more.

I regret that I cannot post the XML Schema and XML-instances I use,
because they are not of my IP. But they are structured in another way,
more dedicated to efficiency.

Bert

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150416/1fb69548/attachment-0001.html

OpenEHR and Oracle XML DB problems

On 16-04-15 09:29, Thomas Beale wrote:
 e still need some kind of schema for XML docs/ messages, but I would 
 not even think of making any persistence be based on XML, especially 
 not XML schema. Probably Relax NG would have been the better one for 
 messages etc.

 Keep XML at the boundaries, that's the key to happiness! I guess JSON 
 with its own schema will replace it in the next couple of years. 
With RelaxNG, IMHO, you cannot communicate structure, RelaxNG only 
serves validation.
So, if I am right, optimizing an XML database using RelaxNG is impossible.
You, can say, that if it validates in a RelaxNG-schema, then it must be 
structured right, but learning a structure from a RelaxNG schema seems 
hard to me.

I don't think JSON wll replace XML, JSON has no attribute-mechanism, and 
must treat everything as data. It has its use for wellknown structures. 
It is efficient.
But if you want JSON to be as rich as XML, then it must be restructured 
as XML, and then it will become XML2.
Which is OK for me, but then we still have to solve the problems with 
XML Schema, but then on JSON-Schema

Bert

OpenEHR and Oracle XML DB problems

On 16-04-15 10:42, Dmitry Baranov wrote:
 I regret that I cannot post the XML Schema and XML-instances I use, because 
 they are not of my IP. But they are structured in another way, more 
 dedicated to efficiency.
 XML schema is intellectual property, I agree, but why might you or somebody 
 else not to provide community with a couple (well, a couple of hundreds will 
 be better) of depersonalized sample instance files? :) We'ld appreciate that 
 very much. I'm a beginner with OpenEHR and it seems to me that there is a 
 lack of OpenEHR instance examples on the Internet; HL7 CDA has plenty of 
 samples and their FHIR has an excellent web site with instance samples 
 repository, in various formats.

Sory Dmitry, I did not explain right. The work I do is not of my IP. I 
work for someone and we agreed he automatically has the IP of my work.

So that is why I can't share the XML Schema's and XML-instances I use.

Bert

OpenEHR and Oracle XML DB problems

On 16-04-15 11:13, Thomas Beale wrote:

 Indeed, it would be a great thing. The reason it doesn't exist so far, 
 is that to be useful we need synthesised data sets that have some 
 realistic statistical spread of values. Since we are talking at 
 multiple levels - not just vital signs measurements, but covariance of 
 all kinds of measurements with assessments (diagnosis etc), plans and 
 orders and actions, the complexity is not trivial.

 A data synthesiser to do this for openEHR would be a fantastic 
 Master's project (hint :).

I use Oxygen, it can generate XML instances to XML Schema's, but first 
we need to change the data-element of version to have type Locatable, or 
Composition.
If wanted, I can generate them too, it is only one minute work.

Bert

 - thomas

 On 16/04/2015 10:02, Dmitry Baranov wrote:
 Diego,
 that'll be great.
 Hope that OpenEHR github owners will provide us with an instance 
 samples repository some day or other :)

 I can generate random sample instances from current archetypes for you
 if you need them. Generated data may not make much sense as it only
 tries to follow the archetype constraints, but it should be enough for
 application testing and benchmark



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

OpenEHR and Oracle XML DB problems

2015-04-15 Thread Bert Verhees

On 15-04-15 15:47, Dmitry Baranov wrote:
 Hi everyone,

 According Bert experience 
 (https://www.linkedin.com/groups/Choice-OpenEHR-persistence-layer-144276.S.208531138),
  one must not try to adopt OpenEHR model to relational storage since almost 
 all popular database engines able to process native XML.

 So I'm experimenting with Oracle XML DB for almost two weeks, and I'm in 
 despair and kindly ask you for help.

 Here is a Github repository where I've collected few files - 
 https://github.com/da-baranov/openehr-ora :
 1) EHR.xsd - flattened OpenEHR XML schema
 2) regschema.sql - a script that creates an Oracle directory where test files 
 should be copied to, registers XML schema and creates a table with 
 XML-schema-based column that matches global version element
 3) composition_1191_0.xml, composition_1322_0.xml and composition_1531_0.xml 
 are test instance files which I borrowed from Pablo Pazos github 
 (https://github.com/ppazos/cabolabs-emrapp)
 4) I'm using Oracle 11.2.0.2.0 Express (for some reasons can't use 12c). The 
 key problem is that Oracle rejects all the instance files producing the 
 following error:

 insert into versions(x)
 values(
xmltype(
  bfilename('OPENEHR', 'composition_1531_0.xml'),
  NLS_CHARSET_ID('AL32UTF8')
)
 )
 -
 ORA-31079: unable to resolve reference to type COMPOSITION
 -

 5) In other cases I faced same error also related to abstract XML type 
 resolution with xsi:type: ORA-31079: unable to resolve reference to type 
 xsd:string. Although all XML schema namespaces were OK and Visual Studio 
 schema validator gives no errors.

 Where am I wrong?


Looks like a namespace-problem. I cannot judge that without seeing your 
XML Schema and XML-file.
And I am not going to look at them. Sorry for sounding harsh, but I am 
not an Oracle specialist.

I use Oracle 12c, so I cannot advise you with your Oracle-version.
You should use 12c, it cannot be an hardware issue.
I have run Oracle 12c on a cheap netbook, with 4G memory.
So, my advise, buy another machine, a cheap one, let it be dedicated for 
Oracle. For developing purpose I have an old Lenovo desktop-machine, I 
bought for 100 Euro as Oracle server.
For demo purpose, as explained, that netbook, runs like hell on both.
For production, of course you need something else.

Install Oracle Linux, Oracle fits best on Oracle Linux.

Just do it, and then it should run fine, although you have to change the 
XML-Schemas (a bit) before registering them to Oracle. I already 
explained to you before what and why.

Anyway, your error-situation may become less ambiguous.

Bert

OpenEHR and Oracle XML DB problems

2015-04-15 Thread Bert Verhees

On 15-04-15 17:19, Dmitry Baranov wrote:
 Sorry Bert ) I had to explain that Oracle 11 is a business requirement, not a 
 hardware limitation.

 Just do it, and then it should run fine, although you have to change the
 XML-Schemas (a bit) before registering them to Oracle. I already
 explained to you before what and why.
 I remember your advise but not sure that changing all the sequences to 
 choices is a right way for many reasons. And I'm almost sure that it's an 
 Oracle bug since other XSD validation tools (visual studio, netbeans and 
 eclipse) say that my instance files are all OK and conform to XML schema.

You are right it is a messy solution, but if you use sequence, like it 
is defined in the XML Schema, you have to take care that all the nodes 
in your XML are in the right/defined order.
I think this is hard to achieve when XML-files are created in 
production, but of course, you can arrange that as an alternative.

I think it is a stupid rule in the XML-Schema standard.
The only alternative is choice, but then you are not able to have the 
counting of the elements validated.
Check the book written by Priscilla Walmsley, she is the all knowing 
saint regarding XML Schema.
If you don't have it, you can check the w3-website, where the standard 
is published, but less comfortable to read.
So, validating completely against XML Schema is not feasible because of 
weakness in the XML-Schema standard.

So why should you then register the XML-Schema in the database?
There is another reason for that, and that is because Oracle is able to 
optimize the querying by using the structures in the XML-Schema. And for 
that purpose, replacing the sequence with choice is not a problem.

I don't know if comparing the results with other products is a reason to 
say that your work is done right.
You should always follow the standard in your analyses, before you 
declare one product buggy and another not.

There is a message on Oracle forum, similar symptoms - 
https://community.oracle.com/message/10778556

I see in that message that there was a patch recommended, did you try 
that? Always use the latest patch level.



 Ok, I'll try 12c this night, thanks.
Maybe on success, you are able to change the business requirement.

good luck.

Bert

ordered in CMultiAttribute

2015-01-29 Thread Bert Verhees

Hi,

I wonder what a use-case might be for the ordered keyword in 
CMultiAttribute.
It complicates software, and seems useless because elements in a list 
can be queried/sorted in any order in the result, as well be queried as 
a single element.

Shouldn't it therefore not be in the AOM, but be something for a 
template to implement?
Thanks for any thoughts

Bert

CRUD Restlet

2015-01-23 Thread Bert Verhees

Although the the stock market-information is a data-object, it is 
generated by a service, and because Rest is (mis)used to communicate 
with services the service must be seen as the addressed resource.
If the service is out of order, or the address to the service is 
misspelled a 404 would be in its place (Restlet does that out of the 
box. And that is right, According the Fielding, the service is the 
resource, not the data it produces.

Any information that can be named can be a resource: a document or 
image, a temporal service

But when the service responses with information, f.e. a specific share 
is removed from the market, so there is no further information, or the 
share is not present at that market, then is that information.
The services runs properly and it gives information. What can be wrong then?

The problem is that Rest was meant to be for resources, as you say, as a 
webserver, the web was also meant for resources, static HTML-pages, that 
is where the http-status (1.1) is about, since it was designed in 1999.

Bit this is not the case anymore. It is often an interface to a service 
instead of a resource, and according to Fielding, so the HTTP-status 
must say something about the service, not about, the information a 
service provides.

By the way, last Sunday I linked to a document which interpreted the 
Fielding dissertation like I do. And an argument on this list came up 
that that link was to a document from 2003, thus, too old.
But the Fielding dissertation is from 2000, 3 years older.

Anyway, we are using Rest as an interface to services, so the status 
must be treated as such.
As long as the service is found and responds to a GET with information, 
it should be treated in the resource-context as a resource that was 
found and in well state.

That is my opinion, and I know not many use Rest this way, so we have to 
think about that.
But isn't that all about OpenEHR, if the argumentation would have been: 
Do as others do. There wouldn't have been OpenEHR at all.

I think, because, Rest is not a standard, it is legitimate to use it in 
another way then most people do, as long as you have a consistent 
process-model.

Let us remind that the way Rest is nowadays used, does not represent a 
consistent process-model.
It returns 404 because of a not found service, and it can return 404 on 
a found and properly functioning service, which returns information.

It was also mentioned in the discussion, is Rest the way to communicate 
with a service oriented architecture, wouldn't SOAP do better?
Because SOAP handles services as Rest should handle them.

Is it possible to find a way to have Rest act more like a service interface?
I think this is easy to do.

But we have been through this discussion, I just wanted to reply to Erik 
who referred to Fieldings dissertation, and now it seems that that 
dissertation can as well be interpreted into my idea about Rest.

Bert


On 23-01-15 10:39, Ralph van Etten wrote:
 Hi Bert,

 So, if the content contains the information that no person with that ID
 is in the system, then that is information, everything went well, the
 class did its work without error, then that is not an error, and one
 could argument that 200 should be returned, or maybe 204, and not 404,
 which means that the resource to look for (which is the call handling
 process/class) was not found.

 You should see a resource as an instance of some data object and not 
 as some process providing access to the data. A resource is a 
 document, not the process providing access to documents.

 Compare it with a normal web server:

 If you try to access a resource (web page) which is not there, it 
 returns a 404.
 Although the process providing the resource exists (the webserver) the 
 resource you are after does not (the web page), hence the 404.

 A 404 means the client was able to connect to the server, but the 
 server was unable to find the information you are looking for.
 Its an error made by the client, not by the server.


 Ralph.

 MedVision360

CRUD Restlet

Ok, you are right, but http is a very generic application layer, not to
designed to serve specific application needs, but designed to serve web
servers which only serve documents.
As you know, a web server is a very generic application, which, from the
time Http was designed, was only recource driven.

Maybe the error is that Rest uses a generic application layer which is
defined as a resource driven application layer, but in fact Rest is used as
a service oriented application protocol. I think that an OpenEhr kernel, or
PayPal-service, or many other Rest using applications are also service
oriented, not only resource oriented, and that therefor, a resource
oriented error handling is unable to serve the needs of a service oriented
application.

You could call that misusing http, because it was not designed for that,
but on the other hand, with some new thinking, Http can be used to serve a
service oriented architecture. Or do you not agree with this statement?

By the way, nowhere is written that Rest must use the Http status mechanism
for communicating application needs. It is written that Rest must used http
statuses for http-needs, and Restlet does do that.

best regards
Bert

Op maandag 19 januari 2015 heeft Peter Gummer
peter.gummer at oceaninformatics.com het volgende geschreven:

Bert Verhees wrote:

The point for me is separation of transport layer and application
layer, and each domain has its own errorhandling.

Hi Bert,

HTTP is not a transport layer protocol:

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

?The *Hypertext Transfer Protocol* (*HTTP*) is an application protocol
http://en.wikipedia.org/wiki/Application_protocol ?

Thanks for the discussion, though. I?ve learned a lot from it.

Peter

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/1b88e832/attachment.html

CRUD Restlet

I checked on how the large companies like Google, Amazon, PayPal, github do
it.

They all have a hybrid solution. They all use an own error schema was
verbal terms, sometimes hierarchical, and they all map their errors to the
http numerical status schema.

This means that a query with no result is qualified as a 404 error. However
this seems unlogical to me, is that how the big guys it do. It is the same
error which is fired when you try to call a non existing method. But the
accompanying message is different.

It is difficult for me to qualify a query which has no result as an error.
Have you ever been sick? No? That is a 404 error.

But on the other hand, that is how the big guys do it.

Bert

Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl het
volgende geschreven:

By the way, nowhere is written that Rest must use the Http status
mechanism for communicating application needs. It is written that Rest must
used http statuses for http-needs, and Restlet does do that.

best regards
Bert

Op maandag 19 januari 2015 heeft Peter Gummer
peter.gummer at oceaninformatics.com
javascript:_e(%7B%7D,'cvml','peter.gummer at oceaninformatics.com'); het
volgende geschreven:

Bert Verhees wrote:

The point for me is separation of transport layer and application
layer, and each domain has its own errorhandling.

Hi Bert,

HTTP is not a transport layer protocol:

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

?The *Hypertext Transfer Protocol* (*HTTP*) is an application protocol
http://en.wikipedia.org/wiki/Application_protocol ?

Thanks for the discussion, though. I?ve learned a lot from it.

Peter

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*

CRUD Restlet

I just had some extra information.

A query with no result would have status 200, for example,
/parties/John+Doe.
When an identified resource is queried, and there is no result, than the
404 will be applicable, for example /party/123456

Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl het
volgende geschreven:

I checked on how the large companies like Google, Amazon, PayPal, github
do it.

They all have a hybrid solution. They all use an own error schema was
verbal terms, sometimes hierarchical, and they all map their errors to the
http numerical status schema.

This means that a query with no result is qualified as a 404 error.
However this seems unlogical to me, is that how the big guys it do. It is
the same error which is fired when you try to call a non existing method.
But the accompanying message is different.

It is difficult for me to qualify a query which has no result as an error.
Have you ever been sick? No? That is a 404 error.

But on the other hand, that is how the big guys do it.

Bert

Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl
javascript:_e(%7B%7D,'cvml','bert.verhees at rosa.nl'); het volgende
geschreven:

By the way, nowhere is written that Rest must use the Http status
mechanism for communicating application needs. It is written that Rest must
used http statuses for http-needs, and Restlet does do that.

best regards
Bert

Op maandag 19 januari 2015 heeft Peter Gummer
peter.gummer at oceaninformatics.com het volgende geschreven:

Bert Verhees wrote:

The point for me is separation of transport layer and application
layer, and each domain has its own errorhandling.

Hi Bert,

HTTP is not a transport layer protocol:

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

?The *Hypertext Transfer Protocol* (*HTTP*) is an application protocol
http://en.wikipedia.org/wiki/Application_protocol ?

Thanks for the discussion, though. I?ve learned a lot from it.

Peter

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*

CRUD Restlet

Thank, Isabel,

You are right, you and others have put me on the right track, I know now 
how to proceed

best regards
Bert


On 19-01-15 09:07, Isabel Rom?n Mart?nez wrote:
 Hi Bert,
 Sorry for my bad english.
 I think that any aproximation is a viewpoint of a problem and that you 
 can solve the same problem from different viewpoints, using different 
 paradigms. The problem is to choose the optimal and when you have no 
 options that mix differents paradigms to find the optimal way to do 
 this... And if you choose a paradigm you should apply it as best as 
 possible, been conforming with it principles always that it is 
 possible and trying not to mix with others if it is not essential, 
 some times this only implies a little rethinking of the solution.

 A service oriented viewpoint and a resource oriented viewpoint could 
 solve the same problem, you only have to model your solution agree 
 with the principles of the selected way, usually one of them is closer 
 to your problem and would give you a better solution (more easy to 
 implement or more clear) if you chose the correct one, sometimes it 
 could be imposible to use only one aproximation and you have to mix 
 them (this could produce more complex and prehaps less interoperable 
 solutions)...

 In this case, if you are using a Rest viewpoint (Rest itself is 
 resource oriented) you should be consecuent with this paradigm, so you 
 must query for a resource.
 In the sample that you use Have you ever been sick? perhaps this is 
 not the correct question/query it could be better if you think in GET 
 your episodies of sick (where your episodies of sick could be 
 expressed as a URL of course: .../isabel/episodies-of-sick
 If this resource could not exist, and this is not an error if it is 
 not in the server, you could use the code response 204 No Content, 
 for example, that means (I copy the RFC)

 The server has fulfilled the request but does not need to return an 
 entity-body, and might want to return updated
 metainformation. The response MAY include new or updated 
 metainformation in the form of entity-headers, which if
 present SHOULD be associated with the requested variant.
 If the client is a user agent, it SHOULD NOT change its document view 
 from that which caused the request to be
 sent. This response is primarily intended to allow input for actions 
 to take place without causing a change to the user
 agent?s active document view, although any new or updated 
 metainformation SHOULD be applied to the document
 currently in the user agent?s active view.
 The 204 response MUST NOT include a message-body, and thus is always 
 terminated by the first empty line after
 the header fields.

 As you could see the metainformation could be applied to the document 
 in the user agent's active view (so it is clear that he has not been 
 sick and this is not an error), the field your previous sick 
 episodies view would remain empty for the user...

 Or you can consider that this resource always has to exist, so in the 
 server the URL .../isabel/episodies-of-sick would return the resource 
 representation episodies-of-sickNo one/episodies-of-sick
 Of course you have to manage it properly in your server side...

 Best Regards
 Isabel Rom?n

 El 19/01/2015 a las 6:59, Bert Verhees escribi?:
 I checked on how the large companies like Google, Amazon, PayPal, 
 github do it.

 They all have a hybrid solution. They all use an own error schema was 
 verbal terms, sometimes hierarchical, and they all map their errors 
 to the http numerical status schema.

 This means that a query with no result is qualified as a 404 error. 
 However this seems unlogical to me, is that how the big guys it do. 
 It is the same error which is fired when you try to call a non 
 existing method. But the accompanying message is different.

 It is difficult for me to qualify a query which has no result as an 
 error.
 Have you ever been sick? No? That is a 404 error.

 But on the other hand, that is how the big guys do it.

 Bert

 Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl 
 mailto:bert.verhees at rosa.nl het volgende geschreven:

 Ok, you are right, but http is a very generic application layer,
 not to designed to serve specific application needs, but designed
 to serve web servers which only serve documents.
 As you know, a web server is a very generic application, which,
 from the time Http was designed, was only recource driven.

 Maybe the error is that Rest uses a generic application layer
 which is defined as a resource driven application layer, but in
 fact Rest is used as a service oriented application protocol. I
 think that an OpenEhr kernel, or PayPal-service, or many other
 Rest using applications are also service oriented, not
 only resource oriented, and that therefor, a resource oriented
 error handling is unable to serve the needs of a service oriented
 application

CRUD Restlet

On 19-01-15 12:06, Gerard Freriks (priv?) wrote:
 Niet een slecht advies: Kijken bij FHIR van HL7

I will check that


 GF

 Gerard Freriks
 +31 620347088
 gfrer at luna.nl mailto:gfrer at luna.nl

 On 19 jan. 2015, at 11:29, Diego Bosc? yampeku at gmail.com 
 mailto:yampeku at gmail.com wrote:

 I will just add that if you are making a server you probably want to
 take a look and how FHIR does things. They have some pretty cool ideas
 for common problems that you can probably reuse (e.g. using atom for
 query responses)



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/a65aa321/attachment-0001.html

CRUD Restlet

On 19-01-15 11:31, Birger Haarbrandt wrote:
 The medrecord openEHR server is also based on REST and worth looking 
 at. There was a lot to learn from for me as the API is pretty neat.

I will check that too, thanks for the links

Bert

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/9e1acdc6/attachment.html

CRUD Restlet

Thanks Ralph

;-)

On 19-01-15 13:10, Ralph van Etten wrote:
 Hi,


 On 01/19/2015 11:31 AM, Birger Haarbrandt wrote:

 The medrecord openEHR server is also based on REST and worth looking at.
 There was a lot to learn from for me as the API is pretty neat.


 Thanks. We do our best to make the REST API of MedRecord as simple as 
 possible. We try to base the development of the API on actual usecases 
 and what kind of information in needed by (UI) clients without 
 requiring the users of our API to have any knowledge about openEHR or 
 know how things should work from a medical point of view.


 This has lead to our current version of MedRecord (which is still work 
 in progress) and can be found here:

 https://mr.dev.medvision360.org/mr/apidocs/#!/

 (see below if you want to try the API)


 Since we want to make it easy for web application to access our APIs, 
 we should use whatever technique works best for web applications. 
 Currently this means we must use REST over HTTP, HATEOAS, JSON 
 documents, JSON schemas and a focus on (good) (API) documentation.

 I do think the REST architecture style is better than most SOAP, CORBA 
 and ESB solutions and it currently is the best way to access remote 
 resources. But doing REST properly is not easy.

 The current API of MedRecord consists of two pieces:
 A fully automatically generated API based on the ADL files. 
 (everything starting with /ehr )
 And an API based on procedures (everything starting with /procedure )

 The main difference is that the procedure API can be used without any 
 knowledge of openEHR. All openEHR difficulties are hidden behind the 
 procedure API which should make the API simple enough to be usable by 
 any (UI) developer not familiar with openEHR or health care.

 These two APIs are different views on the openEHR data stored in a 
 database. This also means we can swap the backend which we are 
 currently using for any other openEHR backend.

 The MedRecord API also comes with Java (and JavaScript) client 
 libraries which hides all the REST stuff which makes accessing 
 resources as simple a single line of code while providing the data as 
 plain old Java objects.

 Also note we have two versions of MedRecord. A version based on XML 
 and a version not based on XML.
 Our current focus lies on the version without XML and this is the 
 version which can be seen in the link above.


 Since our API needs authentication, you can test our API if you go to 
 the following page:

 https://mr.dev.medvision360.org/mr/apidocs/#!/

 and use the text helloletmeinplease as authToken parameter.

 For example:

 https://mr.dev.medvision360.org/mr/ehr?authToken=helloletmeinplease

 lists all EHRs currently in our development server.


 Btw. this answer might be slightly off-topic but I wanted to explain 
 the process of how we developed our current API.


 Ralph.

 MedVision360

CRUD Restlet

thanks, Pablo.

Since Rest is not a standard, it is a matter of agreeing or not. I'm not
sure how to proceed. It is not that having it one way or the other is a lot
of work to implement. It is just, what seems better. I was often stubborn,
Rowing against the general opinion was often to my advantage. I will think
it over.

I wish to thank you all for the discussion and the info.

Best regards
Bert.

Op zondag 18 januari 2015 heeft pazospablo at hotmail.com
pazospablo at hotmail.com het volgende geschreven:

Hi Bert, this is not really a matter of agreeing or not, or if it's good
or bad reusing http status codes: is the way REST services work. If you
don't like it, you should use SOAP.

Every REST API out there uses status codes for app info, twitter, google,

https://dev.twitter.com/overview/api/response-codes

https://developers.google.com/drive/web/handle-errors

This is a really nice guide I use a lot, it helped me to understand the
REST way of doing things
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Bottom line, it is no good or bad, it is the REST way :)

Pablo.

Sent from my LG Mobile

-- Original message--

*From: *Bert Verhees

*Date: *Sat, Jan 17, 2015 8:35 PM

*To: *openehr-technical at lists.openehr.org
javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');;

*Subject:*Re: CRUD Restlet
.

There are good reasons for trying to reuse a few standardized status codes
in HTTP if you can (see Fieldings dissertation etc.) but the codes are
extensible if you really need to invent your own status code.

That is true, but Restlet already uses 404 for a method not found, or an
URL which it can not route to a method.
And the community urges me to also use 404 for a completely other purpose.

In this way my client application can not distinguish what happens and
cannot proceed in its doing.

What should report to the user?

Error 404: Or the party (partyId) you are looking for does not exist in
the system,
or the URL to the method to find the party is wrong,
or you are addressing the wrong server which does not understand the
URL at all

Can you imaging the customer looking. Maybe I should program the webcam
when the message appears, and publish the result on the Internet.

Must be big fun.

Thank you (not) restlet for this

On Sat, Jan 17, 2015 at 9:37 PM, Bert Verhees bert.verhees at rosa.nl
javascript:_e(%7B%7D,'cvml','bert.verhees at rosa.nl'); wrote:

They are mixing the network-layer (HTTP) with the application layer. It is a
very old principle and I learned to not do this. I explained why, below.

Maybe it is your assumption that HTTP is a pure network layer that misleads
you?Maybe the WWW is resembling a giant distributed application/ecosystem and
HTTP is part of it, all layered on top of the network: TCP/IP?

You are right, HTTP is not a network-layer.

But I understood it to be transparent, to the application it serves.

Before I was using SOAP, better error handling, because there was
separation between application and protocol errors.

But thanks for your comments.

Time for a drink (or two)

Bert

// Erik

P.s.

Feel free to complain to Roy Fielding, IETF et.al. about the design of HTTP
and REST but for your own sake please do read relevant parts of his
dissertation first. He explains the design choices very well :-)

If you want to fight more fruitful REST-related battles I am sure you can
find many things on the net that claim to be REST but actually do not fit the
intended purpose of REST and many such designs that are actually not
following the REST design patterns. :-)

___openEHR-technical mailing
listopenEHR-technical at lists.openehr.org
javascript:_e(%7B%7D,'cvml','openEHR-technical at
lists.openehr.org');http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CRUD Restlet


 https://developers.google.com/drive/web/handle-errors


This is exactly my point, 404 is for handling errors, someone not being 
in a hospital-register is not an error. To check if someone is, and he 
isn't, that is not necessarily an error.
It may even be a good thing, that someone never has been ill in a 
specific hospital.
The only thing that a computer, without value judgment can say, is that 
the call iss successful (HTTP-status 200), and the answer is No, he is 
not in the register. That is information.

To call an non-existing service, that is an error, and should return 
404. That is what Restlet also has implemented.

Bert

CRUD Restlet

On 18-01-15 11:32, Diego Bosc? wrote:

You are not asking for a person, you are asking the server for a
specific document about a patient that does not exist. A server can
have records with identifiers 111, 112, 113, etc. which can be about
the same patient or not. If you ask the server for a inexistent
document identifier it gives you 404. Document identifier doesn't mean
patient identifier.

I agree, using the HTTP-status is a tempting idea, because, it looks
like we are requesting a document. But we aren't. REST is not for a
normal document-service. For that a normal webserver is sufficient.
REST is for giving a web-interface to an application, and I ask that
application to create a document about a partyId, and that application
creates the document with information: This person is not in our system

That is not an error, the application gets a command to supply
information about a person in context of that application, and the
application does so.

I think that is good.

It sometimes happens that people are thinking in isolation. I know this
can happen to me. I am then making a point of something no-one seems to
make a point of.
But regardless that risk, I have posted this question to several forums
because I think this is important, and maybe I find support for my way
of thinking.

Bert

El 18/1/2015 11:21, Bert Verhees bert.verhees at rosa.nl
mailto:bert.verhees at rosa.nl escribi?:

https://developers.google.com/drive/web/handle-errors

This is exactly my point, 404 is for handling errors, someone not
being in a hospital-register is not an error. To check if someone
is, and he isn't, that is not necessarily an error.
It may even be a good thing, that someone never has been ill in a
specific hospital.
The only thing that a computer, without value judgment can say, is
that the call iss successful (HTTP-status 200), and the answer is
No, he is not in the register. That is information.

To call an non-existing service, that is an error, and should
return 404. That is what Restlet also has implemented.

Bert

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
mailto:openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/27033f94/attachment.html

CRUD Restlet

On 18-01-15 11:49, Erik Sundvall wrote:
 Why do you see the status 404 as an evil error status but 200 as some 
 totally other kind of status?
Restlet has implemented 404 as an evil error: it means: if it cannot 
route your URL, it returns 404.
So a client application has no useful information from that 404.

The client application has to take further steps to interpret the 404 
status. This is inefficient.

Bert

CRUD Restlet

For information:

See therecommendations by Ethan Cerami: Specialties: Cancer genomics,
bioinformatics, scientific computing, software engineering, project
management.
https://www.linkedin.com/in/ecerami
http://www.oreilly.com/pub/au/806

Read:
http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1

Quoting:

Conclusion:

* *Human Readable Error Messages:* Part of the major appeal of REST
based web services is that you can open any browser, type in the
right URL, and see an immediate response -- no special tools needed.
However, HTTP error codes do not always provide enough information.
For example, if we take option 1 above, and request and invalid book
ID, we get back a 404 Error Code. From the developer perspective,
have we actually typed in the wrong host name, or an invalid book
ID? It's not immediately clear. In Option 3 (DAS), we get back a
blank page with no information. To view the actual error code, you
need to run a network sniffer, or point your browser through a
proxy. For all these reasons, I think Option 4 has a lot to offer.
It significantly lowers the barrier for new developers, and enables
all information related to a web service to be directly viewable
within a web browser.
* *Application Specific Errors:* Option 1 has the disadvantage of not
being directly viewable within a browser. It also has the additional
disadvantage of mapping all HTTP error codes to application specific
error codes. HTTP status codes are specific to document retrieval
and posting, and these may not map directly to your application
domain. For example, one of the DAS error codes relates to invalid
genomic coordinates (sequence coordinate is out of bounds/invalid).
What HTTP error code would we map to in this case?
* *Machine Readable Error Codes:* As a third criteria, error codes
should be easily readable by other applications. For example, the
XooMLe application returns back only human readable error messages,
e.g. Invalid Google API key supplied. An application parsing a
XooMLe response would have to search for this specific error
message, and this can be notoriously brittle -- for example, the
XooMLe server might simply change the message to Invalid Key
Supplied. Error codes, such as those provided by DAS are important
for programmatic control, and easy creation of exceptions. For
example, if XooMLe returned a 1001 error code, a client application
could do a quick lookup and immediately throw an /InvalidKeyException./

Based on these three criteria, here's my vote for best error handling
option:

* Use HTTP Status Codes for problems specifically related to HTTP, and
not specifically related to your web service.
* When an error occurs, always return an XML document detailing the
error.
* Make sure the XML error document contains both an error code, and a
human readable error message. For example:
?xml version=1.0 encoding=UTF-8 ?
error
error_code1001/error_code
error_msgInvalid Google API key supplied/error_msg
/error

By following these three simple practices, you can make it significantly
easier for others to interface with your service, and react when things
go wrong. New developers can easily see valid and invalid requests via a
simple web browser, and programs can easily (and more robustly) extract
error codes and act appropriately.

The Amazon.com web services API follows the approach of returned XML
document can specify an /ErrorMsg/ element.
XooMLe also follows this approach. (XooMLe provides a RESTful API
wrapper to the existing SOAP based Google API).
Another approach is by DAS ( Distributed Annotation System) which always
returns 200 if there was no HTTP-error and has error information in the
HTTP-header, which is less favorable, because it is not human readable,
as a browser does not display the HTTP-header.

---
End Quoting

Best regards
Bert

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/c46a8d6f/attachment.html

CRUD Restlet

The point for me is separation of transport layer and application layer, 
and each domain has its own errorhandling.

I have made my choice. And it seems I am not the only one on the world 
with this choice, which is good news

thanks
Bert


pazospablo at hotmail.com schreef op 18-1-2015 om 19:52:

 The recommendations seem a little weak for me.


 1. Most REST services can not be accessed just by typing the url in 
 the browser. What about security tokens? Or header values? Or sending 
 PUT, POST, PATCH or DELETE?


 2. No serious developer will use just the browser and not any other 
 tools. This is plain dumb. We use a bunch of tools for dev and test, 
 from packet sniffers and REST testers, to javascript consoles and log 
 analyzers.


 3. REST services should be documented, so the developer knows for sure 
 what 404 means in each case and has the correct urls for every resource :)



 Sent from my LG Mobile

 -- Original message--

 *From: *Bert Verhees

 *Date: *Sun, Jan 18, 2015 9:46 AM

 *To: *openehr-technical at lists.openehr.org 
 mailto:openehr-technical at lists.openehr.org;

 *Subject:*Re: CRUD Restlet

 For information:

 See therecommendations by Ethan Cerami: Specialties: Cancer genomics, 
 bioinformatics, scientific computing, software engineering, project 
 management.
 https://www.linkedin.com/in/ecerami
 http://www.oreilly.com/pub/au/806

 Read:
 http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1

 Quoting:

 Conclusion:

   * *Human Readable Error Messages:* Part of the major appeal of REST
 based web services is that you can open any browser, type in the
 right URL, and see an immediate response -- no special tools
 needed. However, HTTP error codes do not always provide enough
 information. For example, if we take option 1 above, and request
 and invalid book ID, we get back a 404 Error Code. From the
 developer perspective, have we actually typed in the wrong host
 name, or an invalid book ID? It's not immediately clear. In Option
 3 (DAS), we get back a blank page with no information. To view the
 actual error code, you need to run a network sniffer, or point
 your browser through a proxy. For all these reasons, I think
 Option 4 has a lot to offer. It significantly lowers the barrier
 for new developers, and enables all information related to a web
 service to be directly viewable within a web browser.
   * *Application Specific Errors:* Option 1 has the disadvantage of
 not being directly viewable within a browser. It also has the
 additional disadvantage of mapping all HTTP error codes to
 application specific error codes. HTTP status codes are specific
 to document retrieval and posting, and these may not map directly
 to your application domain. For example, one of the DAS error
 codes relates to invalid genomic coordinates (sequence coordinate
 is out of bounds/invalid). What HTTP error code would we map to in
 this case?
   * *Machine Readable Error Codes:* As a third criteria, error codes
 should be easily readable by other applications. For example, the
 XooMLe application returns back only human readable error
 messages, e.g. Invalid Google API key supplied. An application
 parsing a XooMLe response would have to search for this specific
 error message, and this can be notoriously brittle -- for example,
 the XooMLe server might simply change the message to Invalid Key
 Supplied. Error codes, such as those provided by DAS are
 important for programmatic control, and easy creation of
 exceptions. For example, if XooMLe returned a 1001 error code, a
 client application could do a quick lookup and immediately throw
 an /InvalidKeyException./

 Based on these three criteria, here's my vote for best error handling 
 option:


   * Use HTTP Status Codes for problems specifically related to HTTP,
 and not specifically related to your web service.
   * When an error occurs, always return an XML document detailing the
 error.
   * Make sure the XML error document contains both an error code, and
 a human readable error message. For example:

 error
 1001
 error_msgInvalid Google API key supplied/error_msg
 /error

 By following these three simple practices, you can make it 
 significantly easier for others to interface with your service, and 
 react when things go wrong. New developers can easily see valid and 
 invalid requests via a simple web browser, and programs can easily 
 (and more robustly) extract error codes and act appropriately.

 The Amazon.com http://Amazon.com web services API follows the 
 approach of returned XML document can specify an /ErrorMsg/ element.
 XooMLe also follows this approach. (XooMLe provides a RESTful API 
 wrapper to the existing SOAP based Google API).
 Another approach is by DAS ( Distributed Annotation System) which 
 always returns 200

CRUD Restlet

 Also, the date of the post you reference is from ~ 2003

The Rest protocol is very old, maybe 15 years, and hasn't changed much, so
are some recommandations. I don't know from which date the recommandation
is to use HTTP- status for application error handling. I don't think that
should be an argument.

And I am not writing client software, so I do not have to follow Api's from
others. I am offering API's. I think a client is best served with an own
defined error-handling instead of using the error-handling of another layer
which is designed for other reasons. This argument was also in that
document.

I was just not sure if my choice was a good one, that was, for me, the
reason for the discussion.
But also on private level I got recommandations to follow my own idea, and
I also found some supporting links.

An application can have own error-handling needs. There was an example in
that document. Similar examples I have too, where the mapping to the HTTP
number schema feels unnatural, or by far too rudimentory. Being
contra-intuitive in application API's is something to avoid, in my opinion.

For example, saying that a resource is not available is a poor API's
choice. Applications can be in need for a much more complex schema of
errors, and it is good if an hierarchical system is possible.

Why is a requested resource not available? Is it locked by the database?
Has it ever been available, is it tomorrow available, has it brought to an
archive system which needs an other Url or method, has the call been routed
to another service or server, and is there something the matter? Just
examples.

I was looking at the PayPal API about authentication, they had defined over
hundred things that can go wrong in an authentication-process. This needs a
fine grained and extensible error-handling.

Another reason is that, for example, the 404 will also be thrown for
HTTP-technical reasons, inside Restlet, it is used for other reasons. It
is confusing for a client with a 404 for application-reasons which need a
entirely other action to be resolved. This was, I thought, also an argument
from the link I posted.

Anyway, I made my choice, and with support from some important people in my
activity-context, so I follow that way.

But thanks again for your arguments, they gave me something to think about.

Bert.

Op zondag 18 januari 2015 heeft pablo pazos pazospablo at hotmail.com
javascript:_e(%7B%7D,'cvml','pazospablo at hotmail.com'); het volgende
geschreven:

 But the recommendations you posted are built over false arguments, like
 the #1. in my list on the previous message.

 Also, the date of the post you reference is from ~ 2003 ...

 IMO the bad news is you will not be able to use a lot of APIs that follow
 principles and conventions you don't like, like the EHRScape ;)

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos

 Subject: Re: CRUD Restlet

 The point for me is separation of transport layer and application layer,
 and each domain has its own errorhandling.

 I have made my choice. And it seems I am not the only one on the world
 with this choice, which is good news

 thanks
 Bert


 pazospablo at hotmail.com schreef op 18-1-2015 om 19:52:




  The recommendations seem a little weak for me.


  1. Most REST services can not be accessed just by typing the url in the
 browser. What about security tokens? Or header values? Or sending PUT,
 POST, PATCH or DELETE?


  2. No serious developer will use just the browser and not any other
 tools. This is plain dumb. We use a bunch of tools for dev and test, from
 packet sniffers and REST testers, to javascript consoles and log analyzers.


  3. REST services should be documented, so the developer knows for sure
 what 404 means in each case and has the correct urls for every resource :)



  Sent from my LG Mobile

 -- Original message--

 *From: *Bert Verhees

 *Date: *Sun, Jan 18, 2015 9:46 AM

 *To: *openehr-technical at lists.openehr.org;

 *Subject:*Re: CRUD Restlet
 For information:

 See the recommendations by Ethan Cerami: Specialties: Cancer genomics,
 bioinformatics, scientific computing, software engineering, project
 management.
 https://www.linkedin.com/in/ecerami
 http://www.oreilly.com/pub/au/806

 Read:

 http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1

 Quoting:

 Conclusion:

- *Human Readable Error Messages:* Part of the major appeal of REST
based web services is that you can open any browser, type in the right URL,
and see an immediate response -- no special tools needed. However, HTTP
error codes do not always provide enough information. For example, if we
take option 1 above, and request and invalid book ID, we get back a 404
Error Code. From the developer perspective, have we actually typed in the
wrong host name, or an invalid book ID? It's not immediately clear. In
Option 3 (DAS), we get back a blank page

CRUD Restlet

On 17-01-15 10:24, Diego Bosc? wrote:

 I agree, 404 seems the right code for this. Http talks about 
 resources: when an internet browser returns a 404 is because the 
 specified resource you are asking for couldn't be found on the server, 
 which is exactly the same use case Bert said (the resource you are 
 trying to delete was not find on the server).


I think the resource which is meant is the method to delete a party. For 
example if the url to the method is wrong, it should return a 404.

Imagine you are writing a client and you check for the 404 or success to 
return, how easy can you misinterpret the return if you, f.e., are 
addressing the wrong server.

I think, using HTTP-errors for application-errors, how tempting this may 
be in some situations, is steaming towards hard to find bugs.

So a client first wants to check if the HTTP-call succeeded, and then it 
wants to know how the application responses to the action.
It does not want a return value which can be ambiguously saying 
something about the HTTP-mechanism or the application, what ever is first.

If this is the normal behaviour in REST, I think it is a failure, which 
we should not take over.

Bert

 El 17/1/2015 2:19, pazospablo at hotmail.com 
 mailto:pazospablo at hotmail.com pazospablo at hotmail.com 
 mailto:pazospablo at hotmail.com escribi?:

 Hi Bert, that's a REST Web Services convention. REST reuses a lot
 of the HTTP infrastructure, like methods, status codes, sone
 headers, etc.


 Sent from my LG Mobile

 -- Original message--

 *From: *Bert Verhees

 *Date: *Fri, Jan 16, 2015 8:18 PM

 *To: *For openEHR technical discussions;

 *Subject:*CRUD Restlet

 I was looking at EHRScape, I should have posted this question
 there, but the Community-page does not show any
 communication-means, only adds.

 And maybe the question is also generic and are more people
 thinking about this.

 I am wondering about the HTTP-errors, they seem to be used for
 communicating application-errors.
 I think this could be an error.

 For example, if you look at the:DELETE /demographics/party/{partyId}

 It can return a 404 with explanation: 404 Not found - the
 specified party was not found (DEMO-6021).

 I think this is possible wrong, because on HTTP-level the call was
 an success, and should therefor return 200, meaning, the request
 is received and understood, and processed.
 In the return-message it should IMHO, if necessary the result and
 error-message on application level.

 Someone thoughts about this?

 Thanks
 Bert

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/6b659678/attachment-0001.html

CRUD Restlet

On 17-01-15 12:00, Diego Bosc? wrote:
 Probably 405 'method not allowed' or just return a generic 400 'bad
 request'. In either case you know it is your client fault.
 Wikipedia is a good start for most common codes. You can see you can
 cover a lot of use cases just with the codes on that page.
 http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Sorry Diego, I disagree with you. There are several reasons for it.
To avoid a repetition of arguments, I leave it

Have a nice day.

Bert

CRUD Restlet

On 17-01-15 11:56, Karsten Hilbert wrote:
 What would be the error code for when the client attempts to
 call a non-existing service on the server ?

Sorry that I come back to this once more. Karsten almost gave a good 
example, I want to explain my cause on a better but similar example.

The same problem also occurs with a GET. The REST-service from EHRScape 
returns a 404 when the party is not found, while the service to get the 
party is found.
GET /demographich/party/{partyid}
In my opinion it should return 200, the application-service to find the 
party is found, understood the request, so there is no HTTP-error, but 
the application returns that the party is not found.
This should be expressed in the result, not in the HTTP-status

So this is a better example, suppose the client calls the wrong server 
with this URL, he probably gets a 404 because the service cannot be 
found on that server.

So, if you make a REST-service giving back a 404 if the HTTP- runs fine, 
but the application cannot find something requested, you are giving an 
ambiguous message to the client, which cannot determine if there was a 
404 on HTTP-level or a 404 on application-level.

I cannot imagine that the designers from RESTlet wanted this ambiguity. 
I think this is wrong.

Another reason why it is wrong to misuse the HTTP-status for 
communicating application errors is that there can be only one 
HTTP-status, and an application may want to communicate more errors.
Where do you put those errors? In the result-data?

Third reason for not using HTTP-status for application errors is that 
there is a limited number of HTTP-statusses, they have a meaning in the 
technical context of the HTTP-protocol.
Suppose you want to communicate an error for which you cannot find a 
good HTTP-number, what do you do?

So I think it is wrong to misuse the HTTP-status for communicating 
application results.

Now I am leaving this subject,  thanks Karsten for your support.

Best regards and have a nice day.
Bert

CRUD Restlet

According to a discussion on StackOverflow, it should be allowed to use 
HTTP-status to communicate application response.

There is a schema
http://i.stack.imgur.com/whhD1.png

Here is another (maybe better)
https://raw.githubusercontent.com/for-GET/http-decision-diagram/master/httpdd.png

The discussion is here
http://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete

There are also conflicting opinions.

But it seems that a big part of the world finds it OK to use 
HTTP-status-codes to use for application-errors as if a partyId is a 
resource like an HTML-document.

So a client cannot distinguish between a missing service and a missing 
representation for an partyId.

If I do this
(GET) http://localhost:8080/oak/demasdaographic/435980543098

(Response generated by Restlet!)

if gives the same result (404) as this
(GET) http://localhost:8080/oak/demographic/435980543098

(404 should be generated by me)

The first error is a not existing service and the second a not found 
object, but, although completely different from origin and type they 
have the same message.

I cannot imagine that this is what people want. But it seems that they do.

Instead I have this below:

My question, why isn't this better? The rest community is making an 
error, aren't they?

Message and Headers
{
description:Demographic Object :435980543098 is not found.
errorcode:OBJECT_NOT_FOUND
}


Status
*200*OK[Show explanation] Loading time:39
Request headers
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/39.0.2171.95 Safari/537.36
Content-Type:text/plain; charset=utf-8
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Response headers
Content-type:application/json; charset=UTF-8
Content-length:98
Server:Restlet-Framework/2.2.3
Accept-ranges:bytes
Vary:Accept-Charset, Accept-Encoding, Accept-Language, Accept
Date:Sat, 17 Jan 2015 22:19:42 GMT






On 17-01-15 21:27, Sebastian Iancu wrote:
 Hi Bert,

 I think Diego emails are right on spot and can give you some hints 
 about RESTful principles.
 Perhaps you should consider that, what you call  'service' is actually 
 the 'application' itself; than details about returned codes wont be 
 that weird anymore. Also, URLs are resource-refs rather than actions - 
 so a bad URL is generally a resource-not-found or a action-not-allowed.
 As far as I know, there are already few openEHR-REST-apis out there, 
 all behaving in a similar if not identical way in what regards 
 returned status codes.

 Sebastian

 On 1/17/2015 6:20 PM, Bert Verhees wrote:
 On 17-01-15 11:56, Karsten Hilbert wrote:
 What would be the error code for when the client attempts to
 call a non-existing service on the server ?

 Sorry that I come back to this once more. Karsten almost gave a good 
 example, I want to explain my cause on a better but similar example.

 The same problem also occurs with a GET. The REST-service from 
 EHRScape returns a 404 when the party is not found, while the service 
 to get the party is found.
 GET /demographich/party/{partyid}
 In my opinion it should return 200, the application-service to find 
 the party is found, understood the request, so there is no 
 HTTP-error, but the application returns that the party is not found.
 This should be expressed in the result, not in the HTTP-status

 So this is a better example, suppose the client calls the wrong 
 server with this URL, he probably gets a 404 because the service 
 cannot be found on that server.

 So, if you make a REST-service giving back a 404 if the HTTP- runs 
 fine, but the application cannot find something requested, you are 
 giving an ambiguous message to the client, which cannot determine if 
 there was a 404 on HTTP-level or a 404 on application-level.

 I cannot imagine that the designers from RESTlet wanted this 
 ambiguity. I think this is wrong.

 Another reason why it is wrong to misuse the HTTP-status for 
 communicating application errors is that there can be only one 
 HTTP-status, and an application may want to communicate more errors.
 Where do you put those errors? In the result-data?

 Third reason for not using HTTP-status for application errors is that 
 there is a limited number of HTTP-statusses, they have a meaning in 
 the technical context of the HTTP-protocol.
 Suppose you want to communicate an error for which you cannot find a 
 good HTTP-number, what do you do?

 So I think it is wrong to misuse the HTTP-status for communicating 
 application results.

 Now I am leaving this subject,  thanks Karsten for your support.

 Best regards and have a nice day.
 Bert

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http

CRUD Restlet

There are good reasons for trying to reuse a few standardized status
codes in HTTP if you can (see Fieldings dissertation etc.) but the
codes are extensible if you really need to invent your own status code.

That is true, but Restlet already uses 404 for a method not found, or
an URL which it can not route to a method.
And the community urges me to also use 404 for a completely other purpose.

In this way my client application can not distinguish what happens and
cannot proceed in its doing.

What should report to the user?

Error 404: Or the party (partyId) you are looking for does not exist
in the system,
or the URL to the method to find the party is wrong,
or you are addressing the wrong server which does not understand
the URL at all

Can you imaging the customer looking. Maybe I should program the webcam
when the message appears, and publish the result on the Internet.

Must be big fun.

Thank you (not) restlet for this

On Sat, Jan 17, 2015 at 9:37 PM, Bert Verheesbert.verhees at rosa.nl
mailto:bert.verhees at rosa.nl wrote:

They are mixing the network-layer (HTTP) with the application
layer. It is a very old principle and I learned to not do this. I
explained why, below.

Maybe it is your assumption that HTTP is a pure network layer that misleads
you?
Maybe the WWW is resembling a giant distributed application/ecosystem and
HTTP is part of it, all layered on top of the network: TCP/IP?

You are right, HTTP is not a network-layer.

But I understood it to be transparent, to the application it serves.

Before I was using SOAP, better error handling, because there was
separation between application and protocol errors.

But thanks for your comments.

Time for a drink (or two)

Bert

// Erik

P.s.
Feel free to complain to Roy Fielding, IETFet.al http://et.al. about the
design of HTTP and REST but for your own sake please do read relevant parts
of his dissertation first. He explains the design choices very well :-)

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/e8cca9ba/attachment.html

ckm

2015-01-06 Thread Bert Verhees

already running again, stupid networks

Does anyone implemented a transformation between AQL and XML?

2014-12-16 Thread Bert Verhees

Depending on how your XML is constructed, it is very easy to convert AQL to
XQuery, or ADL-path to XPath.

Bert

Op dinsdag 16 december 2014 heeft pablo pazos pazospablo at hotmail.com het
volgende geschreven:

 Just curious :)

 I'm adding version control features to EHRServer (
 https://github.com/ppazos/cabolabs-ehrserver) and I want to add some kind
 of AQL support in the future. Right now we have an internal querying model
 that abstracts from the physical database and allows the creation of
 queries for openEHR data from a UI.
 My idea is to have some kind of transformation between the EHRServer query
 model and AQL, and instead of struggle with AQL parsers I would like to do
 some XML transformations to import and export AQL (I do not need to
 actually execute AQL, the execution of the internal query model is working
 ok).

 Comments and ideas are very welcome!

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos



-- 

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141216/3b516583/attachment.html

Defining multiple constraint bindings in AOM/ADL 1.4

2014-10-31 Thread Bert Verhees

On 31-10-14 09:21, Thomas Beale wrote:
 I know, that's why I asked if it is feasible to incorporate this or 
 at least something similar in the transitional 1.4+ since it seems a 
 very important characteristic.


 yes, undoubtedly. I will start a wiki page to try and tease out 
 changes to reverse engineer from ADL 2 into a new ADL 1.5, 1.6 etc. 
 But I'll rely mostly on input of others on this, so this suggestion 
 needs to go there, and any others you have.
I would favor this change, so if there would be a voting, I would vote yes.
I was missing this feature, so I always managed it to handle it by 
misusing text/description.
According http://semver.org/ it would become 1.5: MINOR version when you 
add functionality in a backwards-compatible manner

Bert

Defining multiple constraint bindings in AOM/ADL 1.4

2014-10-31 Thread Bert Verhees

On 31-10-14 10:32, Gerard Freriks wrote:
 Use case: to define an ?ad-hoc? list of codes that might apply and 
 from which one can be choosen without the need to use the terminology 
 service?
Exactly, many times there are only a few codes needed in an 
archetype/dataset and the need to have a terminology-service available 
to resolve some codes in order to use some archetypes would be an 
overkill-requirement, which could also possible unnecessary slow a 
system down.

MedInfo 2015 openEHR tutorials

2014-10-26 Thread Bert Verhees

On 25-10-14 13:58, Thomas Beale wrote:
On 24/10/2014 19:17, Bert Verhees wrote:
OpenEHR is not a standard, it is a formal specification.

http://www.iso.org/iso/home/standards.htm
ISO, What is a standard:

A standard is a document that provides requirements, specifications,
guidelines or characteristics that can be used consistently to ensure
that materials, products, processes and services are fit for their
purpose.

This is such a fun topic I wrote a blog post
http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation/

on it :)

- thomas

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
I replied following to it:

Thomas, you write: ?They still publish documents, not computable
artefacts, standards have no maintenance team, no issue reporting
capability and no update release strategy.?

This not true, at least not at ECMA and ISO.

1) Example in the standard for Microsoft OOXML are XML Schema?s (XSD)
included. So they deliver computable artefacts.

2) They do not only publish standards, but organize international
teamsmeetings of people which create/edit the standards. A standard in a
specific version is stable, it cannot change, it would be unusable if it
was not stable.

3) Maintenance, ISO standards can get updated, there are even fasttracks
, so not the complete standard has to be talked through. An update, of
course, gets a distinguishable version/name/id.

What you write about OpenEHR doing much better as a defacto standard is
not fully correct.

Example: I am missing some computable artefacts. For example, we have
waited five years before the RM-XSD was published in a correct way, and
still there are some inconveniences in it. There were errors in that
XSD, I emailed about it years ago. Now it has been revised, but not
fully, there are still errors I reported in 2009.
It is also not optimal. For example by using xs:sequence instead of
xs:choice, and so enforcing a useless sequence of properties. There are
some more issues, I do not want to discuss them now.

Also, the XSD for OET is still not published, and it is used in software
and by developers. How long are we using templates by now? 10 years?

OpenEHR seems to be in some parts a moving target. A quality-institute
as ISO would not allow this. There are some quality-requirements used by
ISO. The standard is not only created by the designers (stakeholders),
but by worldwide teams and it becomes accepted by vote of the voting
members of ISO.

I would welcome if OpenEHR would become a standard, not only because
many governments do not invest in non-standards, but also for the
quality requirements standardization-bodies pose and for having
worldwide non-stakeholding teams looking at it. I think this is important.

Bert

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141026/d43045e1/attachment.html

MedInfo 2015 openEHR tutorials

Op vrijdag 24 oktober 2014 heeft pazospablo at hotmail.com 
pazospablo at hotmail.com het volgende geschreven:

  Bert, I'm aware of the definition and I use terms in a very specific
 way, I said standard because  that definition fits what openEHR is.


I don't think so. And I think there can be reasons why OpenEhr does not try
to becomes a standard.





  Anyway, we are not discussing definitions but a much broader subject:
 the board being silent in front on community efforts that need them.


You are right, you just used the word standard a few times, and that is not
what it is. That is one reason why I said it, not for discussion.

I agree that there could be done more and could have been done more. It
(the board) could try to apply for standardization, could work for it,
towards it, It could put more effort in education, it could better document
artifacts which are widely used.

I think it is possible that things have to do with each other. That is why
I responded to the word standard.

The board doesn't do these things. It wonders you. In your message, you
indicate that possible they are not aware of what you complain about.

You'll find the names of the members of the board on the website, I think.
You can email them and ask. I hope you tell us what they tell you. Maybe it
is just money. There ain't no such thing as a free lunch.

Good luck
Bert Verhees.


  Pablo Pazos

 www.CaboLabs.com

 -- Original message--

 *From: *Bert Verhees

 *Date: *Fri, Oct 24, 2014 4:17 PM

 *To: *openehr-technical at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');;

 *Subject:*Re: MedInfo 2015 openEHR tutorials
  OpenEHR is not a standard, it is a formal specification.

 http://www.iso.org/iso/home/standards.htm
 ISO, What is a standard:

 A standard is a document that provides requirements, specifications,
 guidelines or characteristics that can be used consistently to ensure that
 materials, products, processes and services are fit for their purpose.

 On 24-10-14 19:20, pablo pazos wrote:

 Thanks for your message Stefan.

  I understand the organizational time does not accompanies the time of
 the community needs.

  For me is very odd that in one hand the Foundation wants to spread the
 standard but in the other do not endorse anyone on the training side.

  Educators  trainers want to spread the standard also, and sometimes
 just saying the foundation supports us and have a web page with our name
 as endorsed trainers allows us to access places that we can't access
 alone, like government working groups. And training people in government is
 a great way of having the standard included in call for proposals for
 projects, and that leads to the industry to catch up. Then the industry
 will need people to work in delivering tools that implements the standard,
 and that people needs training, and so on. *We can create this virtuous
 circle but we need help.*

  For me, training is the best way of spreading the standard and for the
 openEHR-ES community that seem to work for the last 4 years that I'm giving
 the course in spanish. And others follow, like the openEHR-BR community,
 some of them were my students now they have their own openEHR course in
 portuguese (awesome!).


 I'm not sure what's the formal way of putting these issues under the
 consideration of the board(s) and get any feedback from them.

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home

  --
 Date: Thu, 23 Oct 2014 09:52:22 +0200
 From: sauermann at technikum-wien.at
 javascript:_e(%7B%7D,'cvml','sauermann at technikum-wien.at');
 To: openehr-clinical at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-clinical at lists.openehr.org');
 CC: pazospablo at hotmail.com
 javascript:_e(%7B%7D,'cvml','pazospablo at hotmail.com');;
 openehr-technical at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');;
 openehr-implementers at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-implementers at lists.openehr.org');
 Subject: Re: MedInfo 2015 openEHR tutorials

 Dear Pablo!
 Within IHE wee seem to have a similar situation, educators working along
 providing training, trying to expain to the institutional layer, asking
 the institution to take formal measures, so that training and probably even
 exams and certification are harmonised across subgroups and regions. Over
 the years something has sunk in, and we may see an IHE Education group
 sometime soon. This however took some years until both educators and
 institutional layers knew why and how they might benefit from each other.
 In that way I can understand your experience
 So: There seems to be independent multi-site evidence that education is
 a political issue.

 This may help or not, let us all keep the spirit high!
 Greetings from Vienna,
 Stefan

 Stefan Sauermann

 Program Director
 Biomedical Engineering Sciences (Master

MedInfo 2015 openEHR tutorials

In Europe, politicians are afraid to make errors, they are not able to
judge if a specification has a high quality. So they go for standards. This
is in many countries like this.

That is why HL7 always try to standardize their efforts, and the higher the
better. In Europe you go first to your national body, then to the European
body, then to ISO.

Alternatives with a little bit less status are Oasis, W3, OMG, and also
from there you can go to ISO.

I have never heard that OpenEhr tried to become a standard. In these ten
years, they never did, or they did it in silence, or I just missed it, was
on holiday when the announcement was done.

But if I am right, then is that a reason why it will never become important
on government-level in the Netherlands. And in many other countries this is
the same.

No politician in the Netherlands wil ever invest millions in a
specification which did not made it to ISO. That is why the Netherlands
invested 500 millions Euro in a HL7v3 standard. Because it is an ISO
standard, or it was in the traject to become one. Really, 500 millions
Euro, half a billion Euro. Just for a message system for the Netherlands,
based on HL7v3. And the laugh, it failed.

But that doesn't matter, the politicians are safe, they favored ISO
standards. The companies are safe, they got their money, got well paid, and
did what they were asked for. No one ever got fired for choosing an ISO
standard.

Why did it fail? Ten years they had spent 50 million Euro, every year. It
is a long story, but I can summarize it in a few words. I think they did
not want to succeed. They failed for political reasons, they did not want
to do concessions with the majority in parliament. So the parliament blew
it off. They had chosen to fail.

It would be good for the OpenEhr developing companies if a OpenEhr did more
to be acceptable for governments.

Bert




Op vrijdag 24 oktober 2014 heeft Dra Carola Hullin Lucay Cossio 
carolhullin at hotmail.com het volgende geschreven:

 Dear All,

 Please take this observation as a help DISCUSSION rather a critic: but the
 standards difinition is not an awareness issues, instead is a GAP between
 contexts.
 In Latino America and Caribe, there is minimal understanding of what a
 standard isas displayed on Pablo?s answer, so the real use of openEHR
 never is achieved because of this gap.

 I was last week in INFOLAC2014 ,where the goverment of Uruguay and several
 local authorities discussed about standards but the issue was a different
 one. So, I believe that OpenEHR as foundation and its initial team of
 founders of this conceptual and technical framework should lead the
 training contents and validity that developing countries are using.

 I was surprise that Uruguay invested 4 million dollars and the concept of
 openEHR was missing: lost of investment again.

 http://www.agesic.gub.uy/innovaportal/file/1443/1/agesic_agendadigital_2011_2015.pdf


 Hope this contextual information help to get a good quality training
 package from the foundation so then it can be shared around the world.

 Cheers Carol
 (LATAM)



 --
 From: pazospablo at hotmail.com
 javascript:_e(%7B%7D,'cvml','pazospablo at hotmail.com');
 To: bert.verhees at rosa.nl
 javascript:_e(%7B%7D,'cvml','bert.verhees at rosa.nl');;
 openehr-technical at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');
 Subject: Re: MedInfo 2015 openEHR tutorials
 Date: Fri, 24 Oct 2014 19:23:40 +

  Bert, I'm aware of the definition and I use terms in a very specific
 way, I said standard because  that definition fits what openEHR is.


  Anyway, we are not discussing definitions but a much broader subject:
 the board being silent in front on community efforts that need them.


  Pablo Pazos

 www.CaboLabs.com

 -- Original message--

 *From: *Bert Verhees

 *Date: *Fri, Oct 24, 2014 4:17 PM

 *To: *openehr-technical at lists.openehr.org
 javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');;

 *Subject:*Re: MedInfo 2015 openEHR tutorials
  OpenEHR is not a standard, it is a formal specification.

 http://www.iso.org/iso/home/standards.htm
 ISO, What is a standard:

 A standard is a document that provides requirements, specifications,
 guidelines or characteristics that can be used consistently to ensure that
 materials, products, processes and services are fit for their purpose.

 On 24-10-14 19:20, pablo pazos wrote:

 Thanks for your message Stefan.

  I understand the organizational time does not accompanies the time of
 the community needs.

  For me is very odd that in one hand the Foundation wants to spread the
 standard but in the other do not endorse anyone on the training side.

  Educators  trainers want to spread the standard also, and sometimes
 just saying the foundation supports us and have a web page with our name
 as endorsed trainers allows us to access places that we can't access
 alone, like government working

MedInfo 2015 openEHR tutorials

On 25-10-14 02:54, Shinji KOBAYASHI wrote:
 To Bert,
 Thank you for proof-reading. English is too difficult for me,
 Japanese. My understanding is openEHR specs are oriented to base of
 the standards. Could you let me know the better phrase?
Only strong men can admit their weaknesses. So this is a compliment for you.
My English is not very good also, but I come from a language related to 
English, while you come from a completely other part of the languages-world.
--

OpenEHR specs are based on standards, that is right, in fact everything 
in ICT is, but OpenEHR introduces new artifacts and reference models, 
which should be standardized or be in a process to standardization, 
which already poses some requirements regarding to documentation and 
formal definition.

For example, you can express an OpenEHR dataset in XML, en XML is  a 
standard, but the OpenEHR Reference Model is not.
This in opposite to ISO13606 or some HL7 Reference Models, they are also 
ISO standard.

So, to be accepted by an organization that requires standards, it is not 
enough to use XML, but also you should use an XML-Schema/Reference Model 
which is standardized.

Just for illustration:
I remember when ODF (OpenOffice Reference model) became an ISO-standard, 
governments all over Europe planned to switch to OpenOffice because they 
want to work on standards. Microsoft hurried and put in a lot of money 
to get their Office reference Model (OOXML) standardized. It was the 
fist time Microsoft ever was required to standardize something. We saw 
many new countries becoming voting member of ISO, like Malta and Sierra 
Leone, countries with no expertise or experience at all. The whole 
ISO-process regarding this was a farce. You should read about it for 
having a good laugh.
The only reason was because the competition (OpenOffice) had done that.
Since that moment, since the very fast ISO-process which took less then 
a year, government could safely choose for Microsoft again, back to the 
Microsoft Office environment.

Same counts for medical Reference Models, many governments choose HL7, 
only because it is an ISO standard, and only for that reason.
ISO makes it possible for politician which decide about things they 
don't understand (most of them have to) to distinguish quality in a safe 
way.

Bert.

MedInfo 2015 openEHR tutorials

On 25-10-14 05:21, pablo pazos wrote:

 Bottom line, I just see a gap between the foundation and the 
 community, and that gap gets bigger because of language and 
 geografical differences. That's why I created the openEHR course in 
 spanish and the ES community. My proposal is just a help me help you 
 situation.


 Working towards medinfo, I hope we can join ours efforts in creating 
 awareness, but it is not clear for me if we should organize community 
 stuff separated from the foundation stuff or if we can narrow the gap.

I know you are doing a great job. I often see your promotion for course 
in Spanish, on LinkedIn, on Google Plus (maybe). I forgot where, but I 
see it a few times a week.
That is really a good thing.

And it is necessary. The specs are bad learning material, there are also 
not meant for that.

I remember, ten years ago, sitting at the swimming pool with my little 
children, reading OpenEHR-specs. They were hard to read because of their 
formal language.
It is no material for learning. In learning people things, you need to 
come with examples, with stories, let the Reference Models and other 
specs live for people, make it fun to read.

Anyway, I came through, I did my best, and it was rewarded. But many 
people are not able to do that, because they do not have the freedom to 
spend 50 hours or so on something which is not required to learn. And 
reading the OpenEHR specs as a hobby in free time, that is asked too 
much for most of humanity.

I am an independent developer, almost twenty years now. I choose myself 
how to spend my time, and a lot of time is used because I make choices 
which seem irrelevant. But I don't mind. I try to have a Buddhist view 
on it. It are all steps to greater wisdom. I am a lucky bastard.
The master moves from program to program without fear. No failure can 
harm him. Why is this? He is filled with Tao.

But for the other people, young people, needing to study for their 
masters, old managers, need to understand for their decisions, 
politicians, relying on ISO, all these people need easy entrance to 
knowledge. You try to get it of the ground. You should not only do it in 
Spanish, but also in English.
I think you have a good business-case when OpenEHR as an formal 
definition tries to get more status.
But you have a bad business-case if it fails on the market. It is not 
only in your hands.

You can comfort yourself with the thought that nothing in life will be 
done in vain. In everything is a lesson. With the lessons you have 
learned, you later can pick up something else.

But besides that, I hope the communities and foundation will support 
you, because it is important work that you do, for us all. If we want 
something to be a success, we have to reach the hearts and minds.

Have a nice day
Bert

MedInfo 2015 openEHR tutorials

On 25-10-14 13:58, Thomas Beale wrote:
 On 24/10/2014 19:17, Bert Verhees wrote:
 OpenEHR is not a standard, it is a formal specification.

 http://www.iso.org/iso/home/standards.htm
 ISO, What is a standard:

 A standard is a document that provides requirements, specifications, 
 guidelines or characteristics that can be used consistently to ensure 
 that materials, products, processes and services are fit for their 
 purpose.

 This is such a fun topic I wrote a blog post 
 http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation/
  
 on it :)

 - thomas


 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
I commented to it:

I agree Thomas, it is a fun topic, with billions of dollars involved, 
not quite so funny for who is paying them. You and me, the taxpayers.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141025/88a10da3/attachment-0001.html

openEHR-technical Digest, Vol 32, Issue 31

2014-10-08 Thread Bert Verhees

On 07-10-14 22:57, Seref Arikan wrote:
 Knuth, Donald E. Structured Programming with go to Statements. /ACM 
 Computing Surveys (CSUR)/ 6.4 (1974): 261-301.

Did you see the date?

Programming has changed a bit since then
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141007/3cb4f8fb/attachment.html

Archetype Naming proposals - do we need V0?

2014-10-03 Thread Bert Verhees

On 03-10-14 18:36, Thomas Beale wrote:
 On 03/10/2014 16:40, Ian McNicoll wrote:

 When this published v1 archetype needs to go back into review it gets 
 labelled as

 org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build.e34dgtj67856

 or using the uid - 
 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856

 Probably a side issue from Ian's main points, but

 I think that at the system interface (i.e. in any web service 
 interfaces), we should stick to
 org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1

 not UID-based archetype ids. Internal to the system, a translation 
 might be done from the above id to e.g. an instance UID, or something 
 entirely different, that the system wants to use.

 When AQL queries are built, and when data are shared between systems, 
 the multi-axial id should be used - think of it as a safe symbolic id. 
 Actual data can have whatever it likes as ids, as long as it can 
 translate properly between what it uses internally and what the 
 outside world uses.

My main objection against MLHIM was always that it had UUID's as 
element-names. For a programmer this is not very nice.

Bert
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/ad967ab4/attachment.html

Licensing of specs and artifacts

2014-10-02 Thread Bert Verhees

Thanks Silje, that you bring this very important subject under attention.

It was already under attention recently on a LinkedIn discussion, but I
am afraid it did not reach the right people.

I do agree with your point of view, so there is not much discussion,
there is only one small remark. I don't see any point in retaining the
CC-BY-SA license, with extra clause.

First, CC-BY-SA prevents the secret proprietary use of
OpenEHR-archetypes, in industry this can be a reason not to use OpenEHR.
Except from that, CC-BY-SA is not by everyone understood and is a source
of FUD (Fear, Uncertainty, Doubt), even with extra clause, it will
remain a source of FUD.

For information the link to the LinkedEhr discussion, I hope it works

https://www.linkedin.com/groups/Membership-144276%2ES%2E5909661200660054019?trk=groups_most_popular-0-b-ttlgoback=%2Egde_144276_member_5909661200660054019%2Egmp_144276

Best regards
Bert Verhees

On 01-10-14 17:02, Bakke, Silje Ljosland wrote:

Hi everyone,

In light of the recent re-licensing of FHIR
http://www.healthintersections.com.au/?p=2248 using the Creative
Commons CC0 Public Domain Dedication as well as the discussion about
licensing at the 2014 openEHR Roadmap Meeting
http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting
in Lillestr?m on September 16 and 17, I?d like to restart the
discussion on licensing of openEHR specifications and artefacts
(mainly archetypes, but also potentially templates and terminology sets).

As of now, the specifications are licensed using the Creative Commons
Attribution No-Derivatives
http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license,
while the Creative Commons Attribution Share-Alike
http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used
for artefacts. Several issues have been raised about this choice of
licences. Feel free to add to this list, I?m bound to have forgot some
issues:

CC-BY-ND (for specs):

?Theoretically, a hostile takeover of the openEHR Foundation might
leave the openEHR specs dead, as with the CC-BY-ND only the copyright
holder (the Foundation) has the rights to modify them. A forkable
license like for instance CC-BY-SA would solve this issue. Global
registering of the openEHR trademark would keep any derivates to be
branded as ?openEHR?.

CC-BY-SA (for artefacts):

?Commercial implementers might avoid using CC-BY-SA artefacts because
the license requires any /published/ modifications of the work to be
licensed using the same license. This might lead implementers to
believe the license would require them to license their entire
software product as CC-BY-SA. There are several examples of CC-BY-SA
works being used in copyrighted works, such as Wikipedia articles
being used in newspapers, but this is probably reliant on a benign
licensor, which any normal commercial company can?t rely 100% on. The
way I see it, this problem could be solved in one of two ways:

oUse the CC-BY license, which retains the attribution clause, but
doesn?t require any derivative works to use the same license. This has
the disadvantage of enabling proprietary tweaking of archetypes, which
could potentially ruin interoperability.

oRetain the CC-BY-SA license, but add an explicit clause that allows
all implementers to use artefacts in closed-source, proprietary
products with any license they like. Artefacts published by
themselves, as standalone archetypes, templates or terminology sets
would still be bound by the ShareAlike clause. This is supported by
Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus
protocol.

I realise these issues will ultimately be decided by the board of the
openEHR Foundation, but if the community can come to some kind of
consensus on this issue I would hope it?d send them a strong signal.

Kind regards,
*Silje Ljosland Bakke*

Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust

Tel. +47 40203298

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/98dfc483/attachment.html

Licensing of specs and artifacts

2014-10-02 Thread Bert Verhees


For information the link to the LinkedEhr discussion, I hope it works

Of course, this should be: LinkedIN ;-)

(sorry David)



Best regards
Bert Verhees



On 01-10-14 17:02, Bakke, Silje Ljosland wrote:

 Hi everyone,

 In light of the recent re-licensing of FHIR 
 http://www.healthintersections.com.au/?p=2248 using the Creative 
 Commons CC0 Public Domain Dedication as well as the discussion about 
 licensing at the 2014 openEHR Roadmap Meeting 
 http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting 
 in Lillestr?m on September 16 and 17, I?d like to restart the 
 discussion on licensing of openEHR specifications and artefacts 
 (mainly archetypes, but also potentially templates and terminology sets).

 As of now, the specifications are licensed using the Creative Commons 
 Attribution No-Derivatives 
 http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, 
 while the Creative Commons Attribution Share-Alike 
 http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used 
 for artefacts. Several issues have been raised about this choice of 
 licences. Feel free to add to this list, I?m bound to have forgot some 
 issues:

 CC-BY-ND (for specs):

 ?Theoretically, a hostile takeover of the openEHR Foundation might 
 leave the openEHR specs dead, as with the CC-BY-ND only the copyright 
 holder (the Foundation) has the rights to modify them. A forkable 
 license like for instance CC-BY-SA would solve this issue. Global 
 registering of the openEHR trademark would keep any derivates to be 
 branded as ?openEHR?.

 CC-BY-SA (for artefacts):

 ?Commercial implementers might avoid using CC-BY-SA artefacts because 
 the license requires any /published/ modifications of the work to be 
 licensed using the same license. This might lead implementers to 
 believe the license would require them to license their entire 
 software product as CC-BY-SA. There are several examples of CC-BY-SA 
 works being used in copyrighted works, such as Wikipedia articles 
 being used in newspapers, but this is probably reliant on a benign 
 licensor, which any normal commercial company can?t rely 100% on. The 
 way I see it, this problem could be solved in one of two ways:

 oUse the CC-BY license, which retains the attribution clause, but 
 doesn?t require any derivative works to use the same license. This has 
 the disadvantage of enabling proprietary tweaking of archetypes, which 
 could potentially ruin interoperability.

 oRetain the CC-BY-SA license, but add an explicit clause that allows 
 all implementers to use artefacts in closed-source, proprietary 
 products with any license they like. Artefacts published by 
 themselves, as standalone archetypes, templates or terminology sets 
 would still be bound by the ShareAlike clause. This is supported by 
 Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus 
 protocol.

 I realise these issues will ultimately be decided by the board of the 
 openEHR Foundation, but if the community can come to some kind of 
 consensus on this issue I would hope it?d send them a strong signal.

 Kind regards,
 *Silje Ljosland Bakke*

 Coordinator, National Editorial Board for Archetypes, National ICT Norway
 Adviser, RD dept, E-health section, Bergen Hospital Trust

 Tel. +47 40203298



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/26c7bb0b/attachment-0001.html

[openEHR-announce] roadmap 2014 meeting streaming

2014-09-17 Thread Bert Verhees

It didn't work on Linux, though the opening screen was confusing. It
wouldn't work, it said, but still it invited to fill in my name. I did, and
it didn't work.

Just for fun, I looked at the supported platforms, first the 128 versions
of Windows, and in the end was Macintosh. I never heard about that OS.
But Linux was not on the list. You can see which platform they hate most.
It is because. reason we all know. Microsoft hates open. It hates
interoperability.

But in the meantime, my whole Eco-system is running on Linux, my databases,
my Tomcat, my Eclipse, my Oxygen, my github, my five consoles which
remember the git-commands I do ten times a day. Everything stable and fine.

I cannot go to another platform to watch a meeting. I am really sorry for
that.

Suggestions about what to use? I guess you considered Google. I used it a
few times. Or Skype, works also fine.

I hope someone has an idea. But, please, never again Mixrosoft, that is
asking for trouble.

Best regards
Bert

Op dinsdag 16 september 2014 heeft Thomas Beale
thomas.beale at oceaninformatics.com het volgende geschreven:

All who are interested / wanted to follow the meeting, our meeting was
moved to a different venue, and the only streaming we were able to run
LYNC, which is a Microsoft tool. This won't work for people on Linux
unfortunately.

We probably can't do anything about this tomorrow (especially as the wifi
is somewhat limiting at the venue), but we will upload all the sessions as
mp4s or similar, so at least you will be able to listen to the meeting
proceedings.

We are also live updating the wiki pages for each agenda item, with notes
from the floor and presentations.

In the future, we clearly need to be better prepared with a streaming
solution supported by all platforms, with live chat input. Suggestions on
this topic could be made on the technical list.

- thomas beale

___
openEHR-announce mailing list
openEHR-announce at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
announce_lists.openehr.org

[openEHR-announce] roadmap 2014 meeting streaming

2014-09-17 Thread Bert Verhees

On 17-09-14 01:25, Diego Bosc? wrote:
 Not sure if this is referring to the same lync, but maybe it is worth trying

 http://its.uiowa.edu/support/article/4049
 http://uits.arizona.edu/uaconnect/lync/linux
I try to remember for the next time


 2014-09-17 1:20 GMT+02:00 Bert Verhees bert.verhees at rosa.nl:
 It didn't work on Linux, though the opening screen was confusing. It
 wouldn't work, it said, but still it invited to fill in my name. I did, and
 it didn't work.

 Just for fun, I looked at the supported platforms, first the 128 versions of
 Windows, and in the end was Macintosh. I never heard about that OS. But
 Linux was not on the list. You can see which platform they hate most. It is
 because. reason we all know. Microsoft hates open. It hates
 interoperability.

 But in the meantime, my whole Eco-system is running on Linux, my databases,
 my Tomcat, my Eclipse, my Oxygen, my github, my five consoles which remember
 the git-commands I do ten times a day. Everything stable and fine.

 I cannot go to another platform to watch a meeting. I am really sorry for
 that.

 Suggestions about what to use? I guess you considered Google. I used it a
 few times. Or Skype, works also fine.

 I hope someone has an idea. But, please, never again Mixrosoft, that is
 asking for trouble.

 Best regards
 Bert

 Op dinsdag 16 september 2014 heeft Thomas Beale
 thomas.beale at oceaninformatics.com het volgende geschreven:

 All who are interested / wanted to follow the meeting, our meeting was
 moved to a different venue, and the only streaming we were able to run LYNC,
 which is a Microsoft tool. This won't work for people on Linux
 unfortunately.

 We probably can't do anything about this tomorrow (especially as the wifi
 is somewhat limiting at the venue), but we will upload all the sessions as
 mp4s or similar, so at least you will be able to listen to the meeting
 proceedings.

 We are also live updating the wiki pages for each agenda item, with notes
 from the floor and presentations.

 In the future, we clearly need to be better prepared with a streaming
 solution supported by all platforms, with  live chat input. Suggestions on
 this topic could be made on the technical list.

 - thomas beale

 ___
 openEHR-announce mailing list
 openEHR-announce at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-announce_lists.openehr.org


 --
 This e-mail message is intended exclusively for the addressee(s).
 Please inform us immediately if you are not the addressee.


 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Small question about commits and AUDIT_DETAILS.system_id

2014-09-05 Thread Bert Verhees

On 05-09-14 19:06, pablo pazos wrote:
Hi! Thanks for your answers.

It is a little tricky but from Thomas comments, I think that the
system is not a technical term, but is more related to an
organizational term. For example, if I use the same system / service
to hold EHRs from 2 different hospitals, I really have 2 system ids
instead of one. So the system_id doesn't depend on the technical
architecture, but depends on how the business is organized. Is that
correct?

I must admit, that this is confusing to me too.
And I have some more confusing.

That is the ID of a VERSION, which is:
Unique identifier of this version, containing owner_id,
creating_system_id and version_tree_id.

So, if you don't know the creating_system_id of a specific version, you
are not able to find it.
And can there be more same-versions of the same dataset with the same ID
but on different environments?
It would be branching, wouldn't it?
That would be the right solution, the same as with sourcecode, if two
people work on the same checkout they need to go branching.

So I put the Kernel_ID (which is in the config file) in the
creating_system_id, so it stays the same, even if it is clustered, or
moved to another machine.

I can understand if there is a client systemId in the Contribution, or
in the Audit, but it seems, there isn't.
You want to know who put the data there, you want to know when it
happened, so, why should not you want to know where it happened?
I therefor understood the System_id as the machine where the commit
happened, maybe a cell-phone, maybe a device, whatever.

Bert

Again, the description from the specs doesn't help to understand this
(Identity of the system where the change was committed, so it
depends on what a system is for us).

For the next version of the specs I think we can update that
description and maybe give a couple of examples.

What do you think?

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com http://cabolabs.com/es/home

Date: Thu, 21 Aug 2014 09:47:35 +0100
From: thomas.beale at oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Small question about commits and AUDIT_DETAILS.system_id

Heath,

this is correct, you were not wrong for 10 y ;-)

We don't record the name or type or id of the application, and I am
not sure even now if that would be of any use. I can't see that it
would be. The system_id is for exactly the purpose that Heath as
explained here.

- thomas

On 21/08/2014 00:27, Heath Frankel wrote:

Hi Thomas Pablo,

I am finding the words in the this discussion ambiguous, and the
specification does help to clarify. Here is my interpretation of
AUDIT_DETAILS.system_id.

I have an EHR service, which is used by two different application,
one is a hospital system and another a mobile application that may
not be related to the hospital system but share the same EHR
service. When the hospital system and mobile application commits
something they are using the same system_id, the system_id of the
EHR service. If there is an exchange of data between this EHR
service and another organisations EHR service via an EHR extract,
the system ID will be used in the other organisations EHR service
to identify that the commit was performed in the original
organisations system_id.

Therefore, the system_id identifies the system that is assigning
version identifiers in the EHR repository, i.e. the
AUDIT_DETAILS.system_id matches the system_id component of the
version.uid. This is important for distributed versioning.

So in Pablo?s scenario, it is one system of multiple components
with multiple components sharing the same EHR service, the mobile
and the EMR would use the same system_id.

Has my interpretation been wrong for 10 years? If so, then we need
clarity added to the specification.

___ openEHR-technical
mailing list openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140905/9e6ddc33/attachment.html

Cyclic datatypes: OpenEHR virus

2014-05-16 Thread Bert Verhees

On 16-05-14 03:55, pablo pazos wrote:
I mentioned the phases, several times, in my previous messages :)

Maybe Thomas can break that up into more phases.

On 16-05-14 09:16, Thomas Beale wrote:
I think Pablo has summarised some useful things:

* validate based on OPTs - this is a must; it's based on the fact
that all your data are _templated_, not just archetyped
* RM validation pass - you could detect pathological structures at
this point
* archetype (OPT) pass

Nobody should feel bad about having to experiment a bit here. There's
no standard answer yet.

I agree that there is no standard answer, and there will never be one.
There will always be technical progress. That keeps us, developers, at
work. ;-)

I wish more people would discuss their technical working out of the
standards, so we can learn.

I am not familiar with the term OPT. I assume, this is opt-out. As
Pablo gave an example, if some has a DV_TEXT in an archetype, he does
not want a DV_CODED_TEXT at that point.

I agree partly with this. But only if the DV_TEXT is not wildcarded. If
it has an attribute mentioned in the archetype:
DV_TEXT matches { value matches {*} }.
Then there can come nothing but a value-attribute which is a constrained
string, in this case, without constraints. (and if applicable, other
required attributes also)

But if in the archetype is DV_TEXT matches {*} then every attribute is
allowed to use, and it is allowed to derive inheritors from DV_TEXT,
which is DV_CODED_TEXT.

I had this discussion some years ago, at that time you agreed that
inheritance is allowed, according to the standard.
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007041.html

Divergence from the theoretical standard on technical/practical reasons
makes code in the context of that standard less flexible and less
extensible and once diverged code leads to more divergence. It maybe
can even lead to another standard on new premiss, of which I know an
example. But as they say in Fawlty Towers: Never mention the war ;-)

If I misunderstood the term OPTs, please forgive me, it was not with
rhetorical intention.
--
The RM-validation pass is very easy in code. Just check it against the
RM-XSD and let it roll.

Maybe we are not aware, because everything happens in a library. There
may be a performance issue.
Will it be more efficient to check before, what you are checking anyway
afterwards?

Also you do not detect all pathological structures, because the one I
mentioned is perfectly legal in the RM, when DV_TEXT matches {*} is in
the archetype. That makes this example dangerous, it is not possible to
detect by a basic RM-check. But you can find other problems, and have a
quick way out. That is true.

The punishment is for data-sets which are valid, they need more
processor-time to get accepted.
--
I don't understand what is meant with archetype (OPT) pass, so I
cannot comment on that.
-
The one pass situation: the logical path through an archetype is very
hierarchical and very easy.
It is a kind of classical visitor-pattern which is followed, but, in my
case, without unnecessary formalities.

I have rewritten the AOM validation-interpretation three times, every
time to create an XML-validation.
First for XML-Schema, then for RelaxNG, both combined with Schematron.
XML-schema and RelaxNG have shortcomings which are trouble in relation
to the features of the AOM/ADL. Some developers have written workarounds
for that. But that is divergence of the standards.

Now I have rewritten it for schematron-only. But the base-structure
remained the same, just the simple one-pass validation. Schematron seems
to be the best way, for now. The asserts are sorted to the context, so
all tests for a specific node will be done in one group. This avoids, at
validation-time, repeated retrieval of nodes, by the XML-interpreter.

By the way, I have a basic RM-check in my validator, I have converted
the XSD's to Schematron, which is not hard to do. I use it to check for
existence of required attributes, which are not in the archetype, and
check for valid inheritance. But this basic RM validator runs in the
same one-pass validation.

Thanks.
Bert
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/fd52bdb8/attachment-0001.html

Cyclic datatypes: OpenEHR virus

2014-05-16 Thread Bert Verhees

On 16-05-14 12:54, Thomas Beale wrote:

 OPT = Operational Template - it's the fully compiled version of a 
 template. See the Template Designer 
 http://www.openehr.org/downloads/modellingtools for this - it 
 generates them. Or else you can just do a fully flattened template in 
 the ADL 1.5 workbench. I can provide details on this if you need.

Yes, please do. I will read it. Until now, I ignored ADL1.5

Life is difficult enough without it ;-)

But I think, time has come to read about it.

Bert

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/0263da4f/attachment-0001.html

ADL / AOM 1.5 wiki resources have moved to new 'ADL' space

2014-05-16 Thread Bert Verhees

Thanks

I will study it

Bert

On 16-05-14 19:37, Thomas Beale wrote:

Interest in ADL AOM 1.5 is growing daily now.

In order to enable visitors new and old to more easily find the ADL
and AOM pages on the openEHR wiki, I have moved them to a new ADL
space http://www.openehr.org/wiki/display/ADL/ADL+Home. This even
has its own logo, so you can see it more easily when you log into the
wiki.

I have renamed some pages in an effort to obtain better URLs (it's not
always that easy to work out Confluence's rules for URL generation. I
have also re-organised the pages and chosen a space theme that enables
the page structure to be visible on the left hand side.

Unfortunately this may cause some disruption to users who have saved
URLs as favourites. The original top page
http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633 now
includes just a link to the new location.

If anyone experiences any problems, or has complaints, please let me
know on this list or privately.

I am continually trying to improve the usability of these pages, so
feedback from all users is extremely valuable. Please either leave
comments on specific pages, or post on the lists.

thanks

- thomas beale

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/b5b42926/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12648 bytes
Desc: not available
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/b5b42926/attachment-0002.png
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 33934 bytes
Desc: not available
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/b5b42926/attachment-0003.png

Cyclic datatypes: OpenEHR virus

2014-05-14 Thread Bert Verhees

On 14-05-14 12:20, Timothy W. Cook wrote:
 Precisely.  This is why I said before that it is an implementation 
 level issue.  Especially in openEHR or anywhere that you are using a 
 DSL and there are not a existing tools to choose from that have been 
 tested across thousands of use cases.

I guess, you wanted to say: there are existing tools to choose from 
that have been tested across thousands of use cases (without not a)

In that case, I would be interested in an example use case, one of the 
thousands, and according tools, I will be happy to learn from you.


 The implementation programming language, operating system and platform 
 will have an impact on your decisions about allowed recursion depth.

So you advice to stop recursion on an arbitrary point? In that case, we 
have the same strategy, as I already have written a few times last days.

 Take a look at a Google search for patterns for data validation.

Sorry Tim, that is a too easy answer for a man of your qualities.
That is not a useful advice, everyone, even children know you can google 
something.

Why do you bother typing this?

Bert

Cyclic datatypes: OpenEHR virus

2014-05-14 Thread Bert Verhees

On 14-05-14 14:04, Timothy W. Cook wrote:
 It is an illustration of how varied the approaches can be based on the 
 implementation situation. 
I tried googling it, of course. I always try to find an answer by 
myself, before discussing it on a mailinglist.
I got 6 million hits to the question you proposed, and the first 30 were 
not very useful.

I would like to see an approach to one specific problem I discussed 
under this subject-line.
And not that approach that I already proposed/explained myself a few 
times last few days ago.

Can you help me there?

Thanks,
Bert

ADLParser ArchetypeInternalRef

2014-03-21 Thread Bert Verhees

Hi,

I think I found something strange in the ADL-parser.


See following ADL:

attribute3 matches {
 use_node SECTION /items[at0001]
 use_node SECTION /items[at0002]
}
attribute4 cardinality matches {0..*} matches {
 use_node SECTION[at0006] /items[at0002]
 use_node SECTION[at0005] /items[at0001]
}

The nodes where pointed to, exist, they look like this

items cardinality matches {0..*} matches {
 SECTION[at0001] occurrences matches {0..1} matches {*}
 SECTION[at0002] occurrences matches {1..2} matches {*}
}

When I parse this, I come to following questions

At /attribute3, it only occurs once in  the Archetype's-pathNodeMap.
I think that one entry is overwritten by the next, because the path's 
are the same
This is a faulty entry in the archetype.

But /attribute4 is parsed wrong I think.
It should occur twice in the pathNodeMap because the path's shoudl be 
different.
But they do not. And that is because the archetype_node_id is not taken 
into account.

There should, in my opinion, have been two paths
/attribute4[at0006]
/attribute4[at0007]

So if I am right, there is a bug in the code in ADL.jj which parses 
internal-refs, it should add the node_id's

Can someone please comment on this. Repairing may not be that hard

Thanks
Bert Verhees
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140321/9cbb42a9/attachment.html

CIMI archetype examples using latest openEHR AOM ADL

2014-02-19 Thread Bert Verhees

Thanks, Peter,

I must have missed the discussion before, and I checked a bit the 
discussion of December 2012. It was not like I had it in my mind, it was 
more about the way to avoid archetypeId-clashes then about the 
archetypeId-clashes itself, as I yesterday suggested.

However, in the wiki you link to is first time a ID-system described 
after the discussion in 2012, but the messages from 2011 and 2009 
indicate that the problem was identified before the discussion in 2012, 
and I was wrong in thinking that I brought the problem under attention.

I just brought a possible solution under attention.

Thanks for clarifying this.

Bert



On 02/19/2014 06:00 AM, Peter Gummer wrote:
 Bert Verhees bert.verhees at rosa.nl wrote:

 Maybe this discussion has been on this list before December 2012, I must 
 have missed it.

 Hi Bert,

 There was a long discussion 18 months earlier than that one:

   
 http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005941.html

 But a proposed fix for the problem was already being discussed five years ago:

   
 http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-June/004600.html

 And note that the wiki page was created at the same time:

   
 http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts

 Peter


 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CIMI archetype examples using latest openEHR AOM ADL

2014-02-19 Thread Bert Verhees

On 02/19/2014 10:34 AM, Ian McNicoll wrote:
 The
 preferred solution was namespacing use reverse-urls but you and others
 argued for more definitive unique identification via OID/UIDs.
I agree

Bert

CIMI archetype examples using latest openEHR AOM ADL

2014-02-19 Thread Bert Verhees

On 02/19/2014 10:34 AM, Ian McNicoll wrote:
 The
 preferred solution was namespacing use reverse-urls but you and others
 argued for more definitive unique identification via OID/UIDs.
Ooops, send to quickly

I am not anymore so sure if it need to be UIDs. I think now, one year 
later, that organisations need to keep their namespaces tidy, if they do 
not, chaos is likely to happen on their data.

Bert

CIMI archetype examples using latest openEHR AOM ADL

2014-02-18 Thread Bert Verhees

On 02/18/2014 01:36 PM, Ian McNicoll wrote:
 As I understand it, the idea of the ENTRY sub-classes was to remove
 some of this variability in the top-level patterns and strike some
 sort of balance between your two contradictory wishes.
I don't think so.

It is the wish, I know, of all working on Health-ICT-projects/standards 
that their standard will serve the whole world, or at least an important 
part of it.

Because if that happens, all the interoperability problems are gone.

This strong wish motivates many decisions, which, after some time, need 
to be adjusted.

For example, in the OpenEHR, the idea was that CKM would serve the world 
with archetypes, and there would be no need of a strong 
archetypeId-system, because, all archetypes ever to be taken seriously 
were in CKM.
Now it is recognized that this is not the case, and the proposition 
regarding archetypeIds changed.

Now, I can read between your lines that variability should not occur. It 
should be avoided.
This reflects the same old wish for one standard for all.

But not to focus on you, not to focus on you or OpenEHR, just because 
this is close on this list. It happens in all other 
standard-communities. It happens everywhere where they define standards.

Maybe you know the joke, I told it a few times:

Andrea: Sigh, there are 51 HL7 standards, this is bad. I am going to 
solve that, I will create a new HL7 standard which will make all others 
obsolete.
Few months later
Carlos: Sigh, there are 52 HL7 standards, this is bad. I am going to 
solve that, I will create a new HL7 standard which will make all others 
obsolete.
Few months later
Francis: Sigh, there are 53 HL7 standards, this is bad. I am going to 
solve that, I will create a new HL7 standard which will make all others 
obsolete.

A world that speaks one language and sings Song of Joy before sleeping 
will not happen. There will be variability, there will be a free market, 
there will be free software development, there will be good and bad 
frameworks. This will always be.

The best we can do is provide means on which good things can come 
forward and the world has a chance here and there to do better.

By the way, do they in the UK still use British Standard Whitworth?

Have a nice day
Bert

CIMI archetype examples using latest openEHR AOM ADL

2014-02-18 Thread Bert Verhees

On 02/18/2014 03:52 PM, Sebastian Garde wrote:

On 18.02.2014 14:56, Bert Verhees wrote:
For example, in the OpenEHR, the idea was that CKM would serve the
world with archetypes, and there would be no need of a strong
archetypeId-system, because, all archetypes ever to be taken
seriously were in CKM.
Now it is recognized that this is not the case, and the proposition
regarding archetypeIds changed.
Hi Bert,
I think you would find a sufficient number of presentations and papers
from me and others about managing archetypes from around the time when
we started to work on CKM (2007) that would convince you that even
then we were far more realistic as to say that the openEHR CKM will
serve the world with archetypes.
We were and still are just striving towards the (lofty) aim to get as
much agreement/convergence as possible as well as unite the archetype
development efforts where possible.

Hi Sebastian, I remember, it must be a year ago, how much problems I had
to convince this community that the archetypeId-system, which was based
on only a few serious archetypes worldwide, would not do.

You also participated in this discussion. I started that discussion
about here:
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html

Do you see how long ago it was, we needed to have this discussion? Only
a bit more then a year.

That a stronger/better/different archetype-id system is needed is true
in my opinion - but a different story: for starters the archetype-id
system predates CKM (or even any vision of it) by many years as far as
I am aware.
It is true that the CKM archetypes are of high quality (as far as I can
judge), and that their existence is a good thing.
But, archetypes can be much more then only having a specific high
quality contents.

They can, for example be structured, as I am thinking of, for example in
a framework which causes some leaf-nodes to have predictable paths. This
can have good effects on system-performance, data-mining, easy
development, and other aspects.

It is only a thought, not everyone will agree this is necessary, but
that does not mean that it is useless to think in such a way.

I think it is time to make that step forwards in two level modeling
thinking.

regards
Bert

CIMI archetype examples using latest openEHR AOM ADL

2014-02-18 Thread Bert Verhees

Sorry I misunderstood you.

Bert

Op dinsdag 18 februari 2014 heeft Sebastian Garde
sebastian.garde at oceaninformatics.com het volgende geschreven:

On 18.02.2014 16:48, Bert Verhees wrote:

On 02/18/2014 03:52 PM, Sebastian Garde wrote:

On 18.02.2014 14:56, Bert Verhees wrote:

For example, in the OpenEHR, the idea was that CKM would serve the world
with archetypes, and there would be no need of a strong archetypeId-system,
because, all archetypes ever to be taken seriously were in CKM.
Now it is recognized that this is not the case, and the proposition
regarding archetypeIds changed.

Hi Bert,
I think you would find a sufficient number of presentations and papers
from me and others about managing archetypes from around the time when we
started to work on CKM (2007) that would convince you that even then we
were far more realistic as to say that the openEHR CKM will serve the world
with archetypes.
We were and still are just striving towards the (lofty) aim to get as much
agreement/convergence as possible as well as unite the archetype
development efforts where possible.

Hi Sebastian, I remember, it must be a year ago, how much problems I had
to convince this community that the archetypeId-system, which was based on
only a few serious archetypes worldwide, would not do.

You also participated in this discussion. I started that discussion about
here:

http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html

Do you see how long ago it was, we needed to have this discussion? Only a
bit more then a year.

Hi Bert, I am not arguing with that, I am just pointing out that you are
relating two things (CKM and the archetype ids) that are not related in the
way you said.
If anything, the existence of several CKMs around the world now - which
can all talk to each other to get each other's archetypes - *highlights *the
need for a different archetype id system.

As for the one-archetype-per-concept-principle in that discussion you link
to: It is what I said in other words above, the lofty aim to agree where
possible. It is not one step, but rather a very long process with
potentially many archetypes about the same concept in e.g. different
regions/countries in the meantime (and likely more than one forever).
Sebastian

CIMI archetype examples using latest openEHR AOM ADL

2014-02-16 Thread Bert Verhees

I have read the PPT from Thomas which is linked in
http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern

I have some remarks on that. My two cents:

The proposal is written from the point of view of OpenEHR.

Although, I cannot comment on medical content, only from the point of 
view of information/developer.

Unknown future use-cases must be implementable. The OpenEHR RM is too 
semantic to be flexible on the long term.
So, all arguments, coming back a few times, about no need to change the 
RM can safely be dismissed.
Why would one not want to change the RM, when the use of the RM changes.
It is better to have an optimal RM for its purpose, than misusing an RM 
which was designed with other goals in mind.
It is better to learn a lesson than to get stuck on a suboptimal legacy RM.

Thomas agrees in Option 6, which I think is his preferred Option.

So the lesson is: No semantics in the Reference Model.
Also, because of the unknown use-cases, no other constraints on the 
reference-model itself, but still we need predictable query-paths.

This means, the RM cannot provide in this, so predictable query-paths 
should be in the archetype modeling instead of the reference model. The 
enforcement of consistent/predictable paths has to be done by the 
information-analyst when writing or choosing archetypes. The RM only 
need to give as much room as possible to do so.

To the Options:

Option 1:
Because of the no changing of the RM, but no use of semantic RM-classes 
we stick to GENERIC_ENTRIES for this?
The point that the PANEL-information needs to be distinguished from 
TEST-entries is not a real disadvantage. Because we are, in this option, 
not talking about another RM, it must be that we are talking about an 
consistent Archetype-Model. An archetyped schema.
SO it is all in the SECTIONs. For developing a kernel there can be 
consequences when an Archetyped Schema is used, there can be 
kernel-layer which is optimized for using that schema. For example, it 
can be optimized to know where to find the PANEL information.
Maybe that is a good approach, having a kernel-layer optimized in this way.
Software is then aware of the (by archetypes) enforced structure.
This layer be a semantic rich API on a generic working kernel.

Option 2 is ignoring that the COMPOSITION-class is a good class as it 
is, and making a kind of ENTRY-class of it. Plus, that the level of 
possible depth-levels is reduced. Instead of the step in between of 
SECTION, we jump right away to ENTRY-CLUSTER. Also the query-path will 
not be stable because of the archetype-node-ids and the CLUSTER will 
need to be overloaded with semantic information. I think this is a poor 
option.

Option 3, the Uber Model, looks attractive, but there are some 
disadvantages, as I understand well.
Lets assume I understand well:
The Uber archetype will contain lots of unused entries, maybe only 10% 
or less is used in a specific case. Although this delivers a predictable 
path-structure.
But then the kernel-software needs to check that many times, for example 
during data-entry, and also at query-time.
This checking could be avoided if there was an index-entry at the top of 
the Uber-Archetype which would contain information about which entries 
are used.
So to say, a meta-information-entry in the Uber-Archetype.

Option 4 with LINKS does not attract me much because it will need 
subqueries, which will make datamining difficult. The advantage of TESTS 
which can stand independently also can exist in the Uber-model.

For Option 5, I cannot imagine a use-case. It seems hypothetical to me.

So we arrive at Option 6, which seems, considered against the previous 
5, having best of all worlds. And it does not try to keep the RM 
unchanged, although it can be done in an older RM.
But it seems a bit similar to Option 2, which also has no SECTIONs.

In my opinion Option 3 and Option 1 are the best options, but both could 
need an extended specific kernel-layer which is able to use the 
archetype-modeling-structures optimized.
Option 2 and Option 4 are more or less just flattening the structure, 
which will be a disadvantage when there is  a parallel need to handle 
other Archetyped Schemas as well. I don't recognize a need to do that.

Best regards
Bert

Thomas Beale schreef op 15-2-2014 13:12:

 Hi Pablo,

 I don't personally particularly agree with this approach either. There 
 are two other approaches that could be used: the COMPOSITION / SECTION 
 / multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an 
 earlier suggestion of Ian's and mine). I am going to build these 
 models as CIMI archetypes as well, and document the results on the 
 wiki as well. Then we can see the outcomes and judge objectively.

 - thomas

 On 14/02/2014 22:48, pablo pazos wrote:
 Hi Thomas,

 Overviewing the content on the wiki, IMO panels are an specification 
 of sections.

 Is very weird from the modeling point of view to have a composite 
 pattern

Persistence of Compositions

2014-02-06 Thread Bert Verhees

Ralph van Etten schreef op 6-2-2014 9:45:
 At the moment only the functionality required for our use cases is
 implemented. For instance, OpenEHR allows archetype slots with
 wildcards. This is something we do not need for our usecases and
 therefore we have not implemented it yet. There are many things like this.
This brings in a little code-complexity.

I solved it by validating every part against its owns archetype, and 
check the archetype-id's against the wildcard, and if everything fits, 
then the parts can be glued together legally to one dataset, which was, 
in my case, an XML-dataset.

I think there is no other way, because you only know at runtime which 
archetype is going to be used in a slot.

I am afraid you cannot escape this use-case for long time. If I was you, 
I would prioritize this one.

good luck, I am sure you will succeed

Bert



 Eventually I think we will support all OpenEHR requirements but we are
 only planning to implement them when there is a need for them.


 Regards,

 Ralph van Etten
 MEDvision360

Persistence of Compositions

2014-02-06 Thread Bert Verhees

Diego Bosc? schreef op 6-2-2014 10:27:
 I believe that for non leaf nodes I'm sure you can easily check for 
 check form occurrences and types, I don't remember if cardinality was 
 taken into account, I have to check that. For leaf nodes, I don't 
 remember having any trouble specifying that kind of constraints.

Thanks
;)

Bert


 2014-02-06 Bert Verhees bert.verhees at rosa.nl 
 mailto:bert.verhees at rosa.nl:

 Diego Bosc? schreef op 6-2-2014 9:52:
 Regarding consistency checks, we have been able to generate
 schematron rules from the archetypes to check constraints stated
 on the archetype on the XML files. I think it is also what HL7
 people uses for validating instances.

 Hi Diego, I am to using Schematron for validation-purpose, but I
 use it together with RelaxNG, because RelaxNG is better in testing
 structures and Schematron is better in validating simple constraints.
 But creating a RelaxNG from an archetype is difficult, that is
 complex and hard to maintain code.

 But now I see your message, I think it could be possible to create
 Schematron only and check every possible constraint, which mostly
 (not on leaf-nodes) are occurrences and cardinality.

 Do you have every possible constraint in an archetype covered by
 Schematron?

 Bert





 2014-02-06 Birger Haarbrandt birger.haarbrandt at plri.de
 mailto:birger.haarbrandt at plri.de:

 Hi Ralph,

  Am 05.02.2014 um 20:34 schrieb Ralph van Etten
 ralph at medvision360.com mailto:ralph at medvision360.com:
 
  On 02/04/14 17:33, Birger Haarbrandt wrote:
 
  Hi Birger,
 
  Erik's approach
  was to develop a proprietary XML Schema to wrap
 compositions and
  contained entries. Obviously, this might work in a native
 XML database
  like eXist but does not serve our needs.
 
  Could you tell more about why a XML database does not serve
 your needs?
 

 That is because we got both complex and simple data
 structures. For example, we got millions of equally
 structured demographic data and lab values that can perfectly
 be represented in a static data schema. Furthermore, there is
 lots of catalogue data that fits best into relational tables.
 (Another important reason is, that our abailable ETL an BI
 tools are optimized to work with SQL Server...)


 
  Additionally, storing the
  archetypes in a relational fashion is not be our first choice.
 
  Why not?
 

 We have to do the trade off between performance and
 understandability of the data model. Medical data can become
 very complex. As we need to build data marts from our
 database it's more important to understand the data as it's
 not a real-time system. In my opinion that's a lot easier
 when you have data structured in a hierarchical way as a
 document (what XML is perfect for).


 
  Therefore, I'm interested to learn if any of you has
 already spent some
  thoughts about best practices to split compositions into
 individual XML
  documents while keeping the relationship throughout
 different tables
  and/or rows.
 
  I just released information about our archetyped
 MEDrecord. Our goal
  was to create a more friendly API for MEDrecord based on
 archetypes.
  While developing this API it proved to be a small step to
 also generate
  SQL schemas from the archetype so that is what we tried.
  Now we have a version of MEDrecord which stores data in a
 XML database
  and a version which stores data in an SQL database whose
 schema is
  generated using archetypes.
 

 Are both versions available as open source? Yesterday I took
 a look at it (just the code) and was impressed by your work!

  More information about the generated API and schemas can be
 found here:
 
  http://www.medrecord.nl/medrecord-json-api/
 
  We are planning to implement some use cases and then see
 which approach
  (XML database or SQL database) works best.
 
  But like I said, the main goal of the archetyped
 MEDrecord was to
  provide a clean, type safe API to clients and not something
 which can
  store anything without generating some code first.

 I'm wondering about it's capabilities to do validation of
 clinical data against archetypes. Is it possible to
 deserialize openEHR XML and check it for consistency or is it
 a one way ticket so far?

  In time the archetyped MEDrecord might grow

Persistence of Compositions

2014-02-05 Thread Bert Verhees

Hi Ralph,

I am very impressed by the innovativeness and originality of this plan.
It looks, at first sight, like the best two-level-modeling kernel 
architecture I have seen for years.

I trust you that it will work like you say it does, but I haven't looked 
deep enough into that to judge in that way.
Also very good you share this with the world.

You write:
Of course there is room for improvement and maybe it is not enough to 
implement all possibilities of OpenEHR 

I don't know how to understand this.
Do you mean that, for the moment, it is not possible to implement all 
OpenEHR requirements?

Best regards
Bert Verhees

Ralph van Etten schreef op 5-2-2014 20:34:
 On 02/04/14 17:33, Birger Haarbrandt wrote:

 Hi Birger,

 Erik's approach
 was to develop a proprietary XML Schema to wrap compositions and
 contained entries. Obviously, this might work in a native XML database
 like eXist but does not serve our needs.
 Could you tell more about why a XML database does not serve your needs?


 Additionally, storing the
 archetypes in a relational fashion is not be our first choice.
 Why not?


 Therefore, I'm interested to learn if any of you has already spent some
 thoughts about best practices to split compositions into individual XML
 documents while keeping the relationship throughout different tables
 and/or rows.
 I just released information about our archetyped MEDrecord. Our goal
 was to create a more friendly API for MEDrecord based on archetypes.
 While developing this API it proved to be a small step to also generate
 SQL schemas from the archetype so that is what we tried.
 Now we have a version of MEDrecord which stores data in a XML database
 and a version which stores data in an SQL database whose schema is
 generated using archetypes.

 More information about the generated API and schemas can be found here:

http://www.medrecord.nl/medrecord-json-api/

 We are planning to implement some use cases and then see which approach
 (XML database or SQL database) works best.

 But like I said, the main goal of the archetyped MEDrecord was to
 provide a clean, type safe API to clients and not something which can
 store anything without generating some code first.
 In time the archetyped MEDrecord might grow into such a solution, but
 currently, for our use cases this is not important.
 The important aspect is that we can create a clean API quickly which is
 based on archetypes.

 What works best, relational database, native XML database or a
 combination (like PostgreSQL with its XML datatype) is something we
 still have to figure out. Although I see the benefits of using a native
 XML database, I do not believe it will have decent performance any time
 soon on cheap hard- and software for the type of queries we need for
 building user interfaces without adding many more complexities.

 Also, we basically treat archetypes as the schema for the information so
 putting a schemaless database beneath it seems to be a bit of a
 mismatch. Instead we attempt to convert the schema provided by
 archetypes into a schema suitable for relational databases and I must
 say I am quite pleased with the lack of complexity on the server side.
 The server code turned out to be quite straight forward and simple.
 Even the complexity of the generator which converts the schemas is
 manageable.

 Of course there is room for improvement and maybe it is not enough to
 implement all possibilities of OpenEHR but for now it is enough to
 implement the use cases we have in the foreseeable future.
 We plan to develop it as new use cases present themselves instead of
 trying to build something which can do anything first and then see if we
 can fit the use cases in there.


 Regards,

 Ralph van Etten
 MEDvision360

ADL/AOM 1.5 - id-codes unification - the final change

2014-01-02 Thread Bert Verhees

Hi Thomas, best wishes to you too, and all other readers.

ADL is a generic modeling language, one should not stick to the OpenEHR 
RM while defining it.

it looks like a good idea to reflect the structure of an archetype in 
the idCodes, like this:

definition[at]
 list[at.1]
 element[at.1.1]
 datavalue[at.1.1.1]
 element[at.1.2]
 datavalue[at.1.2.1]

But there is a suggestion of ordered elements, but ordering can make 
archetypes immutable towards derived versions in the context of 
backwards compatibility.
Because imagine you want to insert an element, this can be confusing

definition[at]
 list[at.1]
 element[at.1.3]
 datavalue[at.1.3.1]
 element[at.1.1]
 datavalue[at.1.1.1]
 element[at.1.2]
 datavalue[at.1.2.1]

So I would suggest a non-numerical reflection of the structure, or, a 
design which leaves room for inserts, like this.

definition[at]
 list[at.100]
 element[at.100.100]
 datavalue[at.100.100.100]
 element[at.100.20]
 datavalue[at.100.200.100]

After insert this would become this
definition[at]
 list[at.100]
 element[at.100.50]
 datavalue[at.100.50.10]
 element[at.100.10]
 another_datavalue[at.100.100.5]
 datavalue  [at.100.100.10]
 another_datavalue[at.100.100.15]
 element[at.100.20]
 datavalue[at.100.200.10]

Of course, this is limited, but I have seen this kind of constructions 
before, for example in distribution of phone numbers inside a company. 
Building-number, room-number, telephone-number, but this also get 
sometimes messed up in modern buildings in which it is easy to 
restructure rooms.

Bert


On 01/01/2014 04:37 PM, Thomas Beale wrote:

 happy new year and best wishes for 2014. I hope your new year's day is 
 a bright one (unless you live in the UK, in which case it's a lost 
 cause today ;-)

 I have been working in the last few months to produce a final version 
 of ADL/AOM 1.5, based on:

   * existing requirements
 http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633,
   * emerging requirements - Intermountain, CIMI,
   * Harold Solbrig's proposals for terms-as-URIs,
   * Dave Carlson's MDHT
 https://www.projects.openhealthtools.org/sf/projects/mdht// AML
 work at OMG http://www.omg.org/cgi-bin/doc?health/2012-7-1led by
 Robert lario,
   * general feedback on this list, particularly from David Moner's
 group at UPV, where they have implemented different rules
   * implementer feedback

 I have cc:d some relevant people who are not on this list - they might 
 want to consider joining 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org.
  
 If not, please email me and I'll post any views you have on the list, 
 or else feel free to feedback on the wiki page below.

 So here's the proposal. To date, We have been trying to keep ADL/AOM 
 1.5 backwardly compatible at the syntax level for ADL 1.4. However, I 
 think this keeps too many old problems unsolved. I propose a new approach:

   * make the central ADL/AOM 1.5 specifications as clean as possible
   * provide a series of updates to ADL 1.4, coming from the 1.5 specs,
 that are carefully designed to be applied to 1.4 tools, to bring
 them up to date
   o e.g. things like how to post-fit the new identifiers, tuple
 support, annotations, to DAL 1.4 archetype tools
   * provide rules and tooling to deal with differences between
 archetype paths, upon which querying is based
   * provide a 1.4 = 1.5 upgrade tool to completely convert existing
 ADL 1.4 archetypes to the new format

 The latest changes I propose (and have in fact implemented) are 
 primarily about dealing properly with the long-running problem(s) of 
 archetype node ids.

 It's documented here on the wiki 
 http://www.openehr.org/wiki/pages/viewpage.action?pageId=49053703.

 All comments and criticism welcome. If you think the proposal is 
 broken in some way, or could be done better, don't be afraid to say 
 so. Please comment on this list, or for substantive comments, the wiki 
 page is probably better. Let's try and get to a final proposal that 
 works for all ADL/AOM users - not just openEHR. I think that would be 
 a real achievement.

 thanks

 - thomas



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140102/d4d9960c/attachment-0001.html

Musings about a more web-friendly openehr

2013-11-29 Thread Bert Verhees

The dwarf sitting on the shoulder of a giant, moves forward faster, but
sees things the giant cannot see.

They cooperate.

http://upload.wikimedia.org/wikipedia/commons/4/4a/Library_of_Congress%2C_Rosenwald_4%2C_Bl._5r.jpg

On 11/28/2013 02:24 PM, Ingram, David wrote:

Dear Bert,

On behalf of the founding fathers of openEHR, with the longest memory
and record of its evolution from the early nineties, this is just to
say thank you for your Thanksgiving Day Hallelujah -- best Leonard
Cohen style, no doubt! I have to say, slightly ruefully, that if, as
you suggest, we were entrepreneurially driven, then we were somewhat
mad to be so -- a 20 year start up is not seen as good business in the
modern era, I fear!

Not for nothing did we describe the three top priorities of openEHR as
implementation, implementation and implementation, mindful of its very
steep learning curve as it was always very steep for us, too. The
implementers, and we should include the clinical data modellers as
well as the software developers in that term, are the heroes of the
transformation that is coming in health care IT, as a modular and
interoperable architecture gains currency, as it inevitably will. It's
with great pride that we see different and independent foci of openEHR
implementation growing apace in Western Europe, where it all started,
Central and Eastern Europe, Asia and the Far East, Australasia, South
America, and no doubt elsewhere as well, since most hits to the web
site historically have come from North America. In my new parallel
world in OpenEyes, we are seeing its open source applications
beginning to spread and take root, similarly widely.

It was one of the privileges of my career to meet and correspond with
Octo Barnett when he was transforming health care IT and I was a PhD
student travelling the world to meet the founders of the field. In
MUMPS he created a new database paradigm for its time, informed by the
practical needs of medicine and inspired too by his concern for
medical education. In the New Pathways programme at Harvard, as well,
which was one of the early initiatives exploring how innovation was
changing the nature and craft of medicine, and therefore how new
students needed to be taught and learn differently, he showed the
talents of visionary, doughty pioneer and craftsman that are needed to
turn the world upside down. It's a good tradition and example for the
implementers of today to seek to follow.

I'm confident that openEHR is in safe new hands and is not going away.
As always, it's there to play and support whatever roles seem most
fitting, as the modular ecosystem of digital care records, that health
care sorely needs, comes into being.

Thanks again for your kind words and best wishes,

David (Ingram)

So think beyond that. That is one of the good things of the designers
of OpenEHR, and more, the designers of the side effects, like AOM,
which are important beyond the boundary of OpenEHR.

Today is thanksgiving? Let us thank those people for their wonderful
work which started about in the beginning of this millennium, or even
in the end of the previous millennium.

They designed an eco-system without having a technical reference to
build it. They showed the courage of Henry Ford. They were inventing
technical solutions, instead of conforming to technical solutions of
the that time current which is now the past.
I know, through the years, people struggled a lot with how to
implement it. And I know, most of them do not admit that. Every
implementor has to solve his own secret problems. OpenEHR is not an
open developer-community, but it is a community of entrepreneurs which
all want to be the number one.

What would have happened if OpenEHR was designed conforming the
technical possibilities of 1999, would we still have been talking
about it right now?

OK, enough of hallelujah.

What's next

- Tooling is good, but tooling is always situation/platform depending.
It is not a fundamental solution.
- Simplification in order to solve technical problems is conforming to
the past and is not a good way.

We need to think deeper about this.
I did not get in this any further then the path/value combinations,
and insuccession, the short path notation (which makes it in fact more
complicated).

Bert

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/20acd24c/attachment.html

Musings about a more web-friendly openehr

2013-11-29 Thread Bert Verhees

On 11/28/2013 02:43 PM, pablo pazos wrote:
One is, the most important, but not in our hands, make the AOM
important, create RM's above the AOM, use it for other purposes than
OpenEHR only. The more the AOM is used, the less developers will
complain about complexity.

IMO end system developers should not even know about AOM. We can
create stuff that hides that from them and they can just consume APIs
the way they are familiar with, e.g. like they consume Twitter or
Google Maps APIs.
I think you misunderstood.

What I wanted to say, if the AOM is used in a wider/broader field then
OpenEHR, it is something developers get used to, and because of the
broad use they are motivated to get on the learning curve.

In my opinion there are several levels of API-possible. One level is
semantic rich, like createObservation, then there can be, a bit more
generic: createEntry, but it can also be completely generic, like
createObject.

Depending on the reference model the object can be a Locatable, if it is
an OpenEHR or 13606 Reference Model, but as far the AOM concerns,
Locatables do not exists.

The AOM only knows archetypes, an AOM-instance-structure is created by
the ADL-parser, and as the parser eats it, you have a valid AOM-structure.

This is a powerful concept, which can be served by a generic API, but
what that will look like, I don't know.

To overcome acting in the wild, and creating data without predefined
structure, archetypes need to conform to a Reference Model.

So there is a two way validation needed:
One, is the archetype conform the Reference Model? This only is needed
at creating time of the archetype.
The other is are the data conform the archetype?
Many other fine features are also available on base of AOM, like AQL and
templates.

Anyway, that was what I am thinking about when developers know the AOM.
When you have these things organized, you have a generic database-engine
on base of the AOM. I think, very powerful concept.

But there are some black holes, and one of them is the communication
between client and server.

As you know, I do it on base of path/value combinations, but many others
do it on base of a kind of object-instance-natation, DADL or XML or
JSON, or whatever.

Bert
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/0170ea53/attachment.html

archetype node_ids again - looking for final solution

2013-11-28 Thread Bert Verhees

On 11/22/2013 08:07 PM, Thomas Beale wrote:

 I spent a bit of time trawling back through that last discussion on 
 C_OBJECT.node_id (the property that carries at-codes) and whether it 
 should be mandatory or optional, and also whether empty is valid.

 Currently it is mandatory, and can't be empty.

 We need to make the spec work for 2 distinct styles of modelling:

   * 13606 style  - requires an at-code on every node, but only some
 have to be defined in the ontology section
   o in this case, the node codes really are like identifiers only,
 some of which happen to have a 'meaning' define for them
   o the result of this is the ability to do more mechanical
 processing of structures, since absolutely every node has an id.
   * openEHR / CIMI style - at-codes required according to rules needed
 to ensure uniqueness; if present, always defined in ontology
 section; they are optional on any other node;
   o in this case, the node codes (where they exist) really are
 codes, and are always defined as terms
   o the result of this, especially in larger archetypes is far
 fewer node ids (since very few at leaves), and shorter paths.


Let me split a bit this email, to not get confusing
--
Hi Thomas, as you probably know, by now, my kernel works with both 
Reference Models, and has AOM as base-definition, every constraint a RM 
puts above that is for the particular Reference Model. The AOM only 
needs to support it, in fact it is the other way around:
A Reference Model which wants to work with ADL-archetypes, must be able 
to fit in the AOM.
--
I have a question about the mandatory of the node_id. I can read it in 
the specs, you are right, it is there.

It may sound stupid, but that is not how I ever understood this 
requirement. Because C_PRIMITIVE_OBJECT is also derived from C_OBJECT, 
and mostly I see them in OpenEHR-archetypes without node_id.

I checked a few examples and the ADL-parser accepts them with no 
node_id, and returns null for nodeid if there is no nodeid.

In the AOM Java code I find following rule in CObject-constructor
if (nodeID != null  StringUtils.isEmpty(nodeID)) {
 throw new IllegalArgumentException(empty nodeID);
 }

In my feeling, this contradicts with the specs. Or am I wrong? Must be 
something stupid I overlook.

Please put me on the right track!
--

 In theory, in both approaches the ontology section comes out about the 
 same, since the LinkEHR-style ontology only contains at-codes with 
 some 'interesting' or meaningful definition.

 I would think our goal would be that archetypes written by anyone 
 should work in anyone else's tool. At the moment this probably isn't 
 the case:

I think this is because of purpose.
The developers only have their specific purpose in mind, and do not want 
to create an archetype-editor which serves purely the AOM-specs.

At this moment there are only two Reference Models, but it could well be 
possible there are new to come.
Because the AOM concept is very powerful. It can have a life of its own, 
for beyond the purpose of OpenEHR and 13606. Reference models should be, 
as I said, just constraints on the AOM. And if they receive recognition 
in major software-development, then that is a good thing, but it has 
nothing to do with the AOM.

The AOM is (only) a modeling-environment, it must be as wide open as 
possible. So, discussion must not target the internals of the AOM, but 
the reference model.
--


   * the AE and ADL workbench would both complain about archetypes with
 at-codes with no definition in the ontology section
   * LinkEHR would complain about archetypes that had some nodes with
 no at-codes

 As Pablo Pazos said in that previous discussion, we should make this work.

Ah, Pablo said so too? Thanks Pablo!!! It is the first time in years 
someone else except me brings this under attention. (as far as I know, 
maybe I missed some)

I had this discussion a few times on this list, let's say, once every 
two years, and it always brought up a mist of arguments, and in the end 
nothing changed.
That was a bit tiresome, so I left it as it is and did my own thing, and 
that was following the AOM as written by Rong.
Which now seems conflicting against the specs? (please enlighten me)

I think it is important, having good tooling is essentially for the 
acceptance of a standard (AOM is part of an ISO standard, as I believe). 
It is really a pity this fact is not well recognized.

The answer does not look to complicated. But maybe, again?, I am 
overlooking complexities.

Talking about ArchetypeEditor GUI, make the in creation of an 
C_PRIMITIVE_OBJECT the addition of a node_id optional. Create an 
archetype-editor so, that it works conform the AOM.

Musings about a more web-friendly openehr

2013-11-28 Thread Bert Verhees

Reflections on Pablo and Leo, both recognizing the complexity of the RM
and looking for ways how to deal with it.

On 11/28/2013 04:30 AM, pablo pazos wrote:
Hi Leo,

I think simplifying openEHR is not a good strategy. The problem is
that most programmers are not implementing against openEHR specs, they
are implementing against other people's implementations. So they have
the learning curve of the specs + the learning curve of using provider
XWZ tools.

Hi Pablo, you are talking about tooling, which is one way to approach
the complexity-problem. A good way too.
Hide the complexity, behind GUI-based tooling.

Strong points in your attitude towards OpenEHR is that you recognized
the complexity of the RM, and second, that you are making easier the way
to work with it.

But there can be also more fundamentally ways to handle the complexity
and make the learning curve less burdensome.

One is, the most important, but not in our hands, make the AOM
important, create RM's above the AOM, use it for other purposes than
OpenEHR only. The more the AOM is used, the less developers will
complain about complexity.

But as I said, that is not in our hands.

So, what else can we do?

Create a substandard which makes entrance to the AOM less complicated.
That is what Leo is writing about.

I skip some text

/last_name
/person_name
/identities
/details
/person

which would also be much more efficient to store and index, and lead
to more intuitive xpath

//first_name_part[1]/value/text() (: Jan :)
//first_name_part[2]/value/text() (: Peter :)
//last_name_value/value/text() (: Balkenende :)

Hi Leo,

You advertises a simplification to make the AOM better to work with.
This is also an approach, but, simplification means, lost of functionality.
And technical arguments like indexing should not weight in innovation.

Because when you consider current technical arguments in defining
something new, you are not innovating, but you are consolidating.

Henry Ford said: If I asked the people what they want, they would say: A
faster horse.

So think beyond the current boundaries. Do not think of AOM making
simpler to remove a learning curve, or solve technical problems, because
that is conforming to the present, which is already the past one second
later.

So think beyond that. That is one of the good things of the designers of
OpenEHR, and more, the designers of the side effects, like AOM, which
are important beyond the boundary of OpenEHR.

Today is thanksgiving? Let us thank those people for their wonderful
work which started about in the beginning of this millennium, or even in
the end of the previous millennium.

They designed an eco-system without having a technical reference to
build it. They showed the courage of Henry Ford. They were inventing
technical solutions, instead of conforming to technical solutions of the
that time current which is now the past.
I know, through the years, people struggled a lot with how to implement
it. And I know, most of them do not admit that. Every implementor has to
solve his own secret problems. OpenEHR is not an open
developer-community, but it is a community of entrepreneurs which all
want to be the number one.

What would have happened if OpenEHR was designed conforming the
technical possibilities of 1999, would we still have been talking about
it right now?

OK, enough of hallelujah.

What's next

We need to think deeper about this.
I did not get in this any further then the path/value combinations, and
insuccession, the short path notation (which makes it in fact more
complicated).

Bert
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131128/83ee6679/attachment.html

Index in array's in ADL

2013-11-24 Thread Bert Verhees

Op zondag 24 november 2013 schreef Colin Sutton (
Colin.Sutton at ctc.usyd.edu.au):


 i.e. don't use indexes - especially where they contradict the meaning:
  * How can you have two 'first' names?
  * Family names come first in some asian languages.


Hi Colin, the discussion is about syntax, not semantics, and a given
archetype is assumed.

regards,
Bert
 .






-- 

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131124/fac9cddd/attachment.html

archetype node_ids again - looking for final solution

2013-11-23 Thread Bert Verhees

Thomas, thanks for your effort, it is very interesting, but now I am not
able to respond more to it. I'll come back to this in a few days.

Bert

Op vrijdag 22 november 2013 schreef Thomas Beale (
thomas.beale at oceaninformatics.com):


 I spent a bit of time trawling back through that last discussion on
 C_OBJECT.node_id (the property that carries at-codes) and whether it should
 be mandatory or optional, and also whether empty is valid.

 Currently it is mandatory, and can't be empty.

 We need to make the spec work for 2 distinct styles of modelling:

- 13606 style  - requires an at-code on every node, but only some have
to be defined in the ontology section
   - in this case, the node codes really are like identifiers only,
   some of which happen to have a 'meaning' define for them
   - the result of this is the ability to do more mechanical
   processing of structures, since absolutely every node has an id.
- openEHR / CIMI style - at-codes required according to rules
needed to ensure uniqueness; if present, always defined in ontology
section; they are optional on any other node;
 - in this case, the node codes (where they exist) really are codes,
   and are always defined as terms
   - the result of this, especially in larger archetypes is far fewer
   node ids (since very few at leaves), and shorter paths.

 In theory, in both approaches the ontology section comes out about the
 same, since the LinkEHR-style ontology only contains at-codes with some
 'interesting' or meaningful definition.

 I would think our goal would be that archetypes written by anyone should
 work in anyone else's tool. At the moment this probably isn't the case:

- the AE and ADL workbench would both complain about archetypes with
at-codes with no definition in the ontology section
- LinkEHR would complain about archetypes that had some nodes with no
at-codes

 As Pablo Pazos said in that previous discussion, we should make this work.

 Can we arrive at a single set of rules that can accommodate everyone?
  The thing that I think is the greatest point of difficulty isn't node_id
 optionality (since a tool built with this assumption will accommodate
 archetypes with at-codes everywhere), but the question of whether there can
 be codes with no definitions in the ontology.

 The original idea of archetypes was to 'overload' the basic types
 available in a generic information model to have domain level meanings. To
 my mind that is still the basis of the approach, as per this example from
 the blood_match archetype:


 The driver for node codes isn't primarily uniqueness, it is 'meaning'. So
 above we have 3 ELEMENTs representing 'ABO', 'Rhesus' and 'Anti-bodies
 detected', and two others representing 'Antibody' and 'Details' - that's
 the idea of domain 'overloading' of a reference model.

 So it seems logical that:

- any 'overloaded' node should have a definition of its id, otherwise,
why overload?
 - Additionally, it seems obvious that where there are multiple
sibling object nodes under an attribute, they all should have distinct
codes and meanings, since otherwise  you don't know what they mean, and
the archetype isn't doing it's job.
 - It can also be the case that for some nodes, the RM default meaning
(e.g. something like 'OBSERVATION.protocol') needs to be overloaded by a
more specific meaning. So an at-code is added there as well.

 So far so good. I think both camps agree on this - which nodes are
 'semantically overloaded' should always come out the same in a proper
 modelling discussion.

 Now, we also agree (as far as I know) that it's a good idea to be able to
 identify any node in an archetype by a unique path, so that archetype nodes
 can reliably be associated and re-associated with data instance nodes (and
 also processed in all kinds of ways inside design time tools). Due to the
 above requirements, this is more or less guaranteed to be satisfied anyway.

 However, LinkEHR has an additional requirement an id must exist on every
 single object node - including nodes with no special 'meaning', nor
 requiring a uniqueness marker - and so it adds that. It doesn't require
 such nodes to have ontology section definitions, so the ontology isn't
 affected, but it does now mean that there are node ids with no definition
 in the ontology. This is the point of breakage between tools.

 I know the UPV guys have probably explained this before (maybe some years
 ago) but I am struggling to remember why this is needed, and what it adds.
 Can someone provide a summary of the explanation here (and any comments on
 the above)? I think that would help to know where we should go next with
 this.

 - thomas



-- 

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL:

Index in array's in ADL

2013-11-22 Thread Bert Verhees

Op donderdag 21 november 2013 schreef Thomas Beale (
thomas.beale at oceaninformatics.com):

 On 21/11/2013 18:35, Leo Simons wrote:



(: from all the items, take the first one, then take all the ones with
 node id at0009 :)
/*[1][@archetype_node_id=at0009]

(: from all the items, take the first one iff it has node id at0009 :)
/*[@archetype_node_id=at0009 and position()=1]


 i.e., so two predicates in a row act like a pipeline of filters...


Exactly, that is my objection, the example is not a path/location to a
leafnode, but it is a filter, the keyword and can be replaced by
or  and then something different comes out. Very useful in xPath, but not
in leafnode-location-indicator. So as location-indicator the keyword
and is useless, because it cannot be replaced. And that is my second
objection, the use of a meaningless/useless keyword.

The purpose of the path is solely to indicate to which leafnode in an
archetype a DataValue belongs.



[at0009,1]


Exactly, a comma will do, however I currently do not support this, but I
use an index in square brackets [1], but I am going to change that.

So I see, for me, no reason to further discuss this, but I hope others
will, and I am very interested in the outcome.

regards,
Bert


-- 

*This e-mail message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131122/f171d374/attachment.html

Paths in archetyped data

2013-11-22 Thread Bert Verhees

On 11/22/2013 10:44 AM, Thomas Beale wrote:
 as ADL short hand for

 cluster[@archetype_node_id='at0009']/items[@archetype_node_id='at0008', 
 @sibling_id='2'] 


I am not sure about this, sibling_id is the array-index, when I 
understand. What happens in case a dataset changes, for example an item 
is removed from a cluster, in that case all the other datasets should 
need revisiting to have this property changed.

For my idea, the array-index is volatile and calculated at the moment of 
need.

Bert

OpenEHR XML-instances from OpenEHR XSD's, was Index in array's in ADL,

Hi all,

Thank you very much for your response.

First I want to respond to this one. Because there is also an XML issue.
It is not that I want to be unfriendly, but, this also needs to be 
discusses.

I assume, the OpenEHR-XSD's are inspiration for this OpenEHR XML.
I write, inspiration, because it is not possible to use the XSD's for 
definition of XML-instances.
I filed a call yesterday on JIRA for that:
http://www.openehr.org/issues/browse/SPECPR-93

But now I see another problem.
If the element thing (see JIRA) was repaired in the XSD's, then still, 
in my opinion, it would not be possible to come to following XML-fragment.
This is also a point that needs to be discussed.

IMHO, it would look like this:

?xml version=1.0 encoding=UTF-8?
cluster xmlns=http://schemas.openehr.org/v1;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://schemas.openehr.org/v1 file:Structure.xsd 
archetype_node_id=openEHR-EHR-CLUSTER.bert.v1
 items archetype_node_id=at0008
 value
 valueJan/value
 /value
 /items
 items archetype_node_id=at0008
 value
 valuePeter/value
 /value
 /items
 items archetype_node_id=at0009
 value
 valueBalkenende/value
 /value
 /items
/cluster

 I'm just messing around in Oxygen with some XSD's.

Me to ;)

But for the rest, I like the XML-approach of defining paths, although, I 
am not sure about the XPath-style, because I think that XPath is a 
query-language.
That is one of the reasons why I started this discussion.

I happen to be in a renovation of some kernel-internals, and I want the 
path's used to have some kind of legitimacy. That is why I ask you to 
help me thinking about it.

Thanks,
Bert



On 11/19/2013 10:23 PM, Thomas Beale wrote:
 On 19/11/2013 20:08, Bert Verhees wrote:
 Hi Alessandro,

 I think you propose this?

  /items[at0008,1]/value/value = Mark
  /items[at0009,2]/value/value = Rutte

 Either this or Bert's original (if it's legal Xpath) is correct, 
 assuming the data look something like (I just added the outer 
 cluster bit and header to make it work in a tool):

 ?xml version=1.0 encoding=UTF-8?
 cluster xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 archetype_node_id=openEHR-EHR-CLUSTER.bert.v1
 xmlns=http://schemas.openehr.org/v1;
 items xsi:type=CLUSTER archetype_node_id=at0007
 items xsi:type=ELEMENT archetype_node_id=at0008
 value xsi:type=DV_TEXT
 valueJan/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0008
 value xsi:type=DV_TEXT
 valuePeter/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0009
 value xsi:type=DV_TEXT
 valueBalkenende/value
 /value
 /items
 /items
 /cluster

 I'm just messing around in Oxygen with some Xqueries and Xpaths.

 - thomas



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131120/a818369c/attachment-0001.html

Index in array's in ADL

Hi,

The idea below was by Leo Simons in a private discussion, I mention also 
my remarks on it, to ask your opinions on this

If we would have produced this XML from a dataset:
?xml version=1.0 encoding=UTF-8?
cluster xmlns=http://schemas.openehr.org/v1;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://schemas.openehr.org/v1 file:Structure.xsd 
archetype_node_id=openEHR-EHR-CLUSTER.bert.v1
 items archetype_node_id=at0008
 value
 value xsi:type=DV_TEXTJan/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0008
 value xsi:type=DV_TEXT
 valuePeter/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0009
 value xsi:type=DV_TEXT
 valueBalkenende/value
 /value
 /items
/cluster

The XPaths would look like:

/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and 
@archetype_node_id='at0007']/items[position()=1 and 
@archetype_node_id='at0008']/value/value=Jan
/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and 
@archetype_node_id='at0007']/items[position()=2 and 
@archetype_node_id='at0008']/value/value=Peter
/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1' and 
@archetype_node_id='at0007']/items[position()=3 and 
@archetype_node_id='at0009']/value/value=Balkenende

As you can see, I use the attribute archetype_id, which is not in the 
specifications, but also I filed an JIRA for that
http://www.openehr.org/issues/browse/SPECPR-92

But apart from that
There are a few things that I don't like about this XPath notation for 
non-query-purpose.

First is the connecting operator and (in position()=1 and 
@archetype_node_id='at0008'), it is meaningless, because I am not 
defining a logical condition.
The second thing is that items which are different (in 
archetype_node_id) also gets an index-notation, following on the 
previous. (3 in this case)

The problem is that the feel-weight (like we build up over the years) of 
elements with a different archetype_node_id is that it is a completely 
different element, although belonging to the same items-list in code.
In the OpenEHR culture, we tend to omit an index-notation, when the 
element is unique because of its archetype_node_id, but I wonder, is 
that the right thing to do?

So I wonder, is X Path-compatibility the right answer to this?

So, summarizing
three problems with xPath:
- the logical operator and while it is not a query
- the index still counting while different archetype_node_id
- there was one more, but it slipped from my mind, and I have to leave 
right now in a hurry.

Maybe not following xPath-like path-notation is a better idea?

I will reply later to the other mails regarding this

Thank you all very much
Bert





On 11/19/2013 10:23 PM, Thomas Beale wrote:
 On 19/11/2013 20:08, Bert Verhees wrote:
 Hi Alessandro,

 I think you propose this?

  /items[at0008,1]/value/value = Mark
  /items[at0009,2]/value/value = Rutte

 Either this or Bert's original (if it's legal Xpath) is correct, 
 assuming the data look something like (I just added the outer 
 cluster bit and header to make it work in a tool):

 ?xml version=1.0 encoding=UTF-8?
 cluster xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 archetype_node_id=openEHR-EHR-CLUSTER.bert.v1
 xmlns=http://schemas.openehr.org/v1;
 items xsi:type=CLUSTER archetype_node_id=at0007
 items xsi:type=ELEMENT archetype_node_id=at0008
 value xsi:type=DV_TEXT
 valueJan/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0008
 value xsi:type=DV_TEXT
 valuePeter/value
 /value
 /items
 items xsi:type=ELEMENT archetype_node_id=at0009
 value xsi:type=DV_TEXT
 valueBalkenende/value
 /value
 /items
 /items
 /cluster

 I'm just messing around in Oxygen with some Xqueries and Xpaths.

 - thomas



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131120/5ac202d6/attachment.html

Index in array's in ADL

On 11/20/2013 09:53 AM, Diego Bosc? wrote:
 /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008']/value[1]/value=Jan
 /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008']/value[2]/value=Peter
 /cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0009']/value/value=Balkenende
This one indicates one items[at0008]-element with to value-elements in 
it. I don't think that is right.

It should be

/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008'][1]/value/value=Jan
/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0008'][2]/value/value=Peter
/cluster[@archetype_id='openEHR-EHR-CLUSTER.bert.v1']/items[@archetype_node_id='at0009']/value/value=Balkenende

regards
Bert

Index in array's in ADL

]/items[at0008][2]/value/value=Peter
[openEHR-EHR-CLUSTER.bert.v1]/items[at0009]/value/value=Balkenende

Children are similar if they have the same attribute-name,  same 
archetype_node_id, the same archetype_id.

But I think that the notation with the comma is better, I am going to 
use that.

[openEHR-EHR-CLUSTER.bert.v1]/items[at0008,1]/value/value=Jan
[openEHR-EHR-CLUSTER.bert.v1]/items[at0008,2]/value/value=Peter
[openEHR-EHR-CLUSTER.bert.v1]/items[at0009]/value/value=Balkenende

It is not very important, it is just about defining how to define what 
the position of a datavalue/leafnode in the archetype-construct is.

The drawback is that I still need ways to reconstruct paths, etc, for 
compatibility reasons.

Thanks for your helping, and if some one wants to discuss it further, I 
am still open for that.

It would be a good thing if the OpenEHR community would reconsider the 
ways paths are treated

regards
Bert Verhees

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131120/136d221b/attachment.html

Index in array's in ADL

2013-11-19 Thread Bert Verhees

Hi all,

I had following interesting discussion.

Suppose we have a cluster containing name of a person.

There is a field called firstname, and a field called lastname.

The problem is concerning the ADL-path, what should be used.

This is a part of the archetype:

CLUSTER[at0007] occurrences matches {0..1} matches {-- voornamen
items cardinality matches {0..*; ordered} matches {
ELEMENT[at0008] occurrences matches {0..*} matches 
{-- firstname
value matches {
DV_TEXT matches {*}
}
}
ELEMENT[at0009] occurrences matches {0..1} matches 
{-- lastname
value matches {
DV_TEXT matches {*}
}
}
}


This is a hypothecical example, only to explain:

Because at0008 has upper-occurrences of more then 1 ( a person can have 
more then one firstnames)
And at0009 has upper-occurrences of 1 (people only have one last-name 
(in this hypothetical country))

If we want to express data in a path/value combination, what would be 
the best solution?

   /items[at0008][1]/value/value = Jan
   /items[at0008][2]/value/value = Peter
   /items[at0009]/value/value = Balkenende

   /items[at0008][1]/value/value = Jan
   /items[at0008][2]/value/value = Peter
   /items[at0009][1]/value/value = Balkenende

   /items[at0008][1]/value/value = Jan
   /items[at0008][2]/value/value = Peter
   /items[at0009][3]/value/value = Balkenende

Or would another solution be better?
Thanks in advance for suggestions.

Kind regards
Bert Verhees

Index in array's in ADL

2013-11-19 Thread Bert Verhees

Hi Alessandro,

I think you propose this?

  /items[at0008,1]/value/value = Mark
  /items[at0009,2]/value/value = Rutte

regards
Bert Verhees


Alessandro Torrisi schreef op 19-11-2013 20:19:
 i would say

  /items[at0008,1]/value/value = Mark
  /items[at0008,2]/value/value = Rutte

 Alessandro



 On 19 November 2013 13:57, Diego Bosc? yampeku at gmail.com 
 mailto:yampeku at gmail.com wrote:

 Hi Bert,

 Personally I would use:

   /items[at0008]/value[1]/value = Jan
   /items[at0008]/value[2]/value = Peter
   /items[at0009]/value/value = Balkenende

 Regards

 2013/11/19 Bert Verhees bert.verhees at rosa.nl
 mailto:bert.verhees at rosa.nl:
  Hi all,
 
  I had following interesting discussion.
 
  Suppose we have a cluster containing name of a person.
 
  There is a field called firstname, and a field called lastname.
 
  The problem is concerning the ADL-path, what should be used.
 
  This is a part of the archetype:
 
  CLUSTER[at0007] occurrences matches {0..1} matches {-- voornamen
 items cardinality matches {0..*; ordered}
 matches {
 ELEMENT[at0008] occurrences matches
 {0..*}
  matches {-- firstname
 value matches {
 DV_TEXT matches {*}
 }
 }
 ELEMENT[at0009] occurrences matches
 {0..1}
  matches {-- lastname
 value matches {
 DV_TEXT matches {*}
 }
 }
 }
 
 
  This is a hypothecical example, only to explain:
 
  Because at0008 has upper-occurrences of more then 1 ( a person
 can have more
  then one firstnames)
  And at0009 has upper-occurrences of 1 (people only have one
 last-name (in
  this hypothetical country))
 
  If we want to express data in a path/value combination, what
 would be the
  best solution?
 
/items[at0008][1]/value/value = Jan
/items[at0008][2]/value/value = Peter
/items[at0009]/value/value = Balkenende
 
/items[at0008][1]/value/value = Jan
/items[at0008][2]/value/value = Peter
/items[at0009][1]/value/value = Balkenende
 
/items[at0008][1]/value/value = Jan
/items[at0008][2]/value/value = Peter
/items[at0009][3]/value/value = Balkenende
 
  Or would another solution be better?
  Thanks in advance for suggestions.
 
  Kind regards
  Bert Verhees
 
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 -- 
 Alessandro Torrisi


 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131119/15339995/attachment.html

Polishing node identifier (at-codes) use cases.

2013-09-27 Thread Bert Verhees

Bert

On 09/27/2013 05:20 PM, Thomas Beale wrote:

Bert,

can you raise an issue on SPECPR
http://www.openehr.org/issues/browse/SPECPR - that's the issue
tracker that we use to feed specification work. If you just paste most
of this post in as the description that will be enough to get back to
this when more people can get involved (which will be fairly soon).

thanks

- thomas

On 26/09/2013 11:21, Bert Verhees wrote:

In my system it is not useful to preload archetypes, because,
archetypes are only parsed once in my system.
That is when they are saved in the system. They are parsed in order
to create a RNG/Schematron definition.

ok, so the downstream form of an archetype you are using is a
Schematron schema - so that's the thing that needs to be stored.

OK, I misunderstood that part of the discussion, having a form of
XML-schema is a representation of an archetype, which can be for
specific purposes like validation more efficient then the
archetype-object, depending on the technical architecture of the kernel.

It seems that we agree on that.

That is used to validate the data, and if new data are entered,
then they will be checked against that RNG/Schematron definition,
not against the parsed archetype.
The schema is loaded in microseconds and the validation takes one
second.

After the data are validated, they are stored in an XML-database,
and they will never be validated again. They are ready for
XPath-queries and XQueries, and all kind of complicated handling
without even looking at an archetype.

right - that sounds like all other archetype-based systems I know of.

So the refusal to specify a archetype_id in the specs is, in my
architecture, bad for performance, because it forces extra
archetype-parsing, so I have that property without the consensus
with the specs, and I do not see it as a waste. I make sure that
when I have to export data to an OpenEHR system, I will put the
archetype_id in the archetype_node_id property.

but the specs already specify archetype_details, which contains the
archetype id. And you can detect that easily in a schematron schema
I guess. So you can easily figure out that you are on one of those
nodes. Is the real problem simply that the syntax of what is in
archetype_node_id on one of those nodes - an archetype_id rather
than an at-code - causes some problem in your processing? I am not
clear on what though... are you trying to use the at-code texts at
runtime? Are they also in the Schematron schema?

We are not talking about the OpenEHR reference model, but about
archetyped data-handling.

I have two arguments, the first one is most simple to explain, so I
start with that.
--
1)
*A golden rule in design is that attribute-names should indicate what
they are there for.*

We are not writing obfuscated code, but readable code, because the
cold war is finished, and we do not need to confuse the Russians
anymore, so we can safely honor this rule.

This means, an attribute (in the ADL common notation) which contains
the archetypeNodeID should be called archetype_node_id and an
attribute containing an archetypeId should be called archetype_id and
it is confusing to use the attribute archetype_node_id to store both,
and even, which makes it worse, without indication about what is in it.
--
2)
The second argument is a more technical issue and a bit difficult to
explain, but I try with an example:

Imagine you have extracted an XML-path in your datastorage which says
../details[@archetype_node_id=at0001]/items[@archetype_node_id=at0003]/.

Say, your client software wants to build a GUI, and uses the
ontology-information to create the GUI-control-indicators and
help-information. I think this is possible to do that that way. It
makes dynamic GUI-building possible.
This example-path above is easy to find and will not cause any
complicated handling.

But in the current situation, the path can look like:
../details[@archetype_node_id=at0001]/items[@archetype_node_id=openEHR-EHR-ITEM_LIST.address.v1]/.

First Step: Now the GUI software wants to have a container-control
which contains the items, and it looks in the ontology of the
containing data-set-archetype to find the archetype_node_id:
openEHR-EHR-ITEM_LIST.address.v1

It does not find it, because it is not there.

Second Step: Now you suggest that the software should look if there
is an archetypeDetails attribute, to see if there is another
archetype to be used for ontology search. This is one step extra the
software needs to do.

Should it do this at every archetypeNodeId, or only if search did not
give a result? That is a statistical question, which workaround will
be applied more and cost more on the long term. Maybe some tricks may
help, and we get tricky software.

Third Step: Then, the archetype_node_id

Polishing node identifier (at-codes) use cases.

2013-09-26 Thread Bert Verhees

Op 25-9-2013 22:47, Thomas Beale schreef:
On 25/09/2013 00:53, Bert Verhees wrote:

sure - if you have a separate property to store the archetype id, it
is empty in 95% of all object instances, and also you need a class
invariant to prevent it being filled at the same time as the
archetype_node_id (at-code) property.

I must disagree, it is very common in archetypes, I think it is in
90% of the archetypes that the root of a definition also has a node_id.

It's 100% ;-)

But what i meant was that in any instance structure, say a
Composition, most of the nodes in the data tree will have an at-code
in archetype_node_id, only a few - the archetype root points - will
have archetype ids.

The at-node corresponding to the root point is just the at code
(or a specialised version of that). Putting that in the data is not
much use.

People could use it for some ontology-message. I don't understand why it
is there when it is not allowed to use, or when it is not possible to
retrieve the connected information. Again this is some small thing in
the specs which has no purpose while people could expect it. This is
caused in chain reaction by the other, I think, ambiguous spec. Because
the other spec makes it impossible to query the atcode from the
definition of an archetype.

I must say that this is not very nice defined.

-- skip skip
--

but the Xpath engine doesn't need to do this. It just processes the
query paths it finds in the queries. It doesn't need to know what
archetypes were used to structure it.

Not quite so, XPath can have properties as path-arguments, and it must
possible to query for certain objects with a specific archetype_id and
another specific node_id. Since the root of the definition is allowed to
have an node_id, one can expect people use it, so there can be a need to
query them.

As I said before, as a builder/designer of a two level modeling system,
you cannot predict which archetypes people use. And you must be sure
that the archetypes they use, can be used safely, which is not always
the case in the current specs, because there may be possible information
which cannot be reached at query-time.

-- skip skip
--

My suspicion from what you are saying is that you are not doing a
pre-load of operational templates into your back-end system. If you
had that, the query service can work very optimally.

It depends if it is wished to have archetypes pre-loaded. If you run a
kernel as a public service, and there are hundreds of archetypes
operational, then it will cost a lot of memory to pre-load them all.
The parsing an archetype should not be done more then once in its
lifetime, it is expensive and unnecessary computing, especially when the
archetypes are large. Saving them preloaded is a real memory-eater.

In my system it is not useful to preload archetypes, because, archetypes
are only parsed once in my system.
That is when they are saved in the system. They are parsed in order to
create a RNG/Schematron definition.

That is used to validate the data, and if new data are entered, then
they will be checked against that RNG/Schematron definition, not against
the parsed archetype.
The schema is loaded in microseconds and the validation takes one second.

After the data are validated, they are stored in an XML-database, and
they will never be validated again. They are ready for XPath-queries and
XQueries, and all kind of complicated handling without even looking at
an archetype.

So the refusal to specify a archetype_id in the specs is, in my
architecture, bad for performance, because it forces extra
archetype-parsing, so I have that property without the consensus with
the specs, and I do not see it as a waste. I make sure that when I have
to export data to an OpenEHR system, I will put the archetype_id in the
archetype_node_id property.

Thanks for the discussion, sorry that we could not find an agreement.

regards
Bert
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130926/f2bcfd23/attachment.html

Polishing node identifier (at-codes) use cases.

2013-09-26 Thread Bert Verhees

ok, so the downstream form of an archetype you are using is a
Schematron schema - so that's the thing that needs to be stored.

It seems that we agree on that.

That is used to validate the data, and if new data are entered, then
they will be checked against that RNG/Schematron definition, not
against the parsed archetype.
The schema is loaded in microseconds and the validation takes one
second.

After the data are validated, they are stored in an XML-database, and
they will never be validated again. They are ready for XPath-queries
and XQueries, and all kind of complicated handling without even
looking at an archetype.

right - that sounds like all other archetype-based systems I know of.

So the refusal to specify a archetype_id in the specs is, in my
architecture, bad for performance, because it forces extra
archetype-parsing, so I have that property without the consensus
with the specs, and I do not see it as a waste. I make sure that when
I have to export data to an OpenEHR system, I will put the
archetype_id in the archetype_node_id property.

but the specs already specify archetype_details, which contains the
archetype id. And you can detect that easily in a schematron schema I
guess. So you can easily figure out that you are on one of those
nodes. Is the real problem simply that the syntax of what is in
archetype_node_id on one of those nodes - an archetype_id rather than
an at-code - causes some problem in your processing? I am not clear on
what though... are you trying to use the at-code texts at runtime? Are
they also in the Schematron schema?

We are not talking about the OpenEHR reference model, but about
archetyped data-handling.

I have two arguments, the first one is most simple to explain, so I
start with that.
--
1)
*A golden rule in design is that attribute-names should indicate what
they are there for.*

We are not writing obfuscated code, but readable code, because the cold
war is finished, and we do not need to confuse the Russians anymore, so
we can safely honor this rule.

This means, an attribute (in the ADL common notation) which contains the
archetypeNodeID should be called archetype_node_id and an attribute
containing an archetypeId should be called archetype_id and it is
confusing to use the attribute archetype_node_id to store both, and
even, which makes it worse, without indication about what is in it.
--
2)
The second argument is a more technical issue and a bit difficult to
explain, but I try with an example:

Imagine you have extracted an XML-path in your datastorage which says
../details[@archetype_node_id=at0001]/items[@archetype_node_id=at0003]/.

Say, your client software wants to build a GUI, and uses the
ontology-information to create the GUI-control-indicators and
help-information. I think this is possible to do that that way. It makes
dynamic GUI-building possible.
This example-path above is easy to find and will not cause any
complicated handling.

But in the current situation, the path can look like:
../details[@archetype_node_id=at0001]/items[@archetype_node_id=openEHR-EHR-ITEM_LIST.address.v1]/.

First Step: Now the GUI software wants to have a container-control which
contains the items, and it looks in the ontology of the containing
data-set-archetype to find the archetype_node_id:
openEHR-EHR-ITEM_LIST.address.v1

It does not find it, because it is not there.

Second Step: Now you suggest that the software should look if there is
an archetypeDetails attribute, to see if there is another archetype to
be used for ontology search. This is one step extra the software needs
to do.

Should it do this at every archetypeNodeId, or only if search did not
give a result? That is a statistical question, which workaround will be
applied more and cost more on the long term. Maybe some tricks may help,
and we get tricky software.

Third Step: Then, the archetype_node_id in that archetype to search for
is invisible for the software, because, it is not in the path. So, this
step is a more complicated, the software needs to know which
archetype_node_id belongs to the root of that archetype, and then it can
find in the ontology section what the description is.

This all could be so much easier, and efficient when the extracted path
looked like:
../details[@archetype_node_id=at0001]/items[@archetype_id=openEHR-EHR-ITEM_LIST.address.v1

Polishing node identifier (at-codes) use cases.

2013-09-25 Thread Bert Verhees

Op 24-9-2013 19:54, Thomas Beale schreef:
 On 24/09/2013 00:10, Bert Verhees wrote:


 For that reason I believe specifications should very carefully 
 specify things. I'll give a very simple example. The openEHR 
 specifications routinely specify which properties of a class are 
 mandatory, optional, and which String fields have to be non-empty. 
 Even those simple things help save time.

 What time do you save? Allowing developers to write sloppy code 
 because they don't need to check for a null-value?
 Do you think that professional programmers are not able to apply 
 basic programming rules, to check for a null value when retrieving 
 data from a database or external source?

 I don't know which quality of software-development you expected in 
 the OpenEHR community when writing this spec, but it does not seem 
 that you had much confidence in developers, at that time.

 it's not developers like you or many of the other careful, thoughtful 
 and professional people on these lists. But there are huge numbers of 
 developers out there whose main job is implementing something else, 
 but who have to quickly 'put something together' for this or that 
 project, typically in a department of health, hospital or other 
 provider site. These people have to write code in a rushed way, and 
 will inevitably solve things as fast as possible without deep 
 contemplation. And yet - those pieces of software routinely end up in 
 real health data processing environments. So the aim of the specs is 
 to reduce errors by this kind of development.

 Like I said, particular choices in the specs to achieve that might be 
 wrong, and the community here needs to help improve that.

So we can stop this discussion right here. I respect that you wanted to 
express your opinion on my message, but there is no need for me to 
comment on this. We agree that shit happens all the time, but apart from 
that that you will support a change of spec regarding the empty string 
representing a null value issue.

But we have the other issue of having one property to store two 
different things without indication what is stored. You call having a 
property which is not often used a waste.


 A waste of a data-property?

 I do not understand what you are trying to say.  Do you mean that 
 there are occasions in which a specific property is useless?
 Because it is not used? Then I must say that OpenEHR has a lot of 
 waste, because there are many properties which are not used all the time.
 :)

 sure - if you have a separate property to store the archetype id, it 
 is empty in 95% of all object instances, and also you need a class 
 invariant to prevent it being filled at the same time as the 
 archetype_node_id (at-code) property.

I must disagree, it is very common in archetypes, I think it is in 90% 
of the archetypes that the root of a definition also has a node_id. So 
in that case both can occur simultaneously. But in the path only the 
archetype_id will occur, and it is easier for a programmer to find which 
one is the archetype_id if it is in a separate property.

And anyway, I don't think a seldom used property is a waste. It is only 
bits and bytes, and there is hardly any code involved having this 
property. But as I showed in example, not having this property can make 
many thousands of lines code-execution necessary. That is a waste.

We, system-builders, and special system-designers like you, do not 
decide which archetypes are going to be used.
There are archetypes of megabytes, they exist. I don't think it is wise 
to have them, but it is that modeling is not always focused on 
performance, but more on academical medical ideas.
We, builders of two level modeling systems, we must be able to live with 
this kind of academic exercises.

But those archetypes cost one second ore more, just parsing on a medium 
speed computer.
You don't want to do this unnecessary, you don't want to parse that kind 
of archetypes at every data-entry. It breaks your system.

Because there is no sure way of analyzing a string and find out if it is 
an archetype_node_id or an archetype_id in slotted situations besides 
parsing and analyzing the archetype, this will make the situation of 
having one property for two different values inefficient, and in some 
situations dramatic inefficient.
 One way is:
 Having different instances, connected via a not in the specs defined 
 connection indicating that one instance should be placed inside the 
 property of another instance.
 Talking about errors, here is a situation in which the specs fail to 
 indicate how the connection must be made, and it is left to implementors.

 Seeing that the spec fail to specify this (and the specs want to 
 protect us against simple programming-errors), we must conclude that 
 the specs want us to really implement archetype-slotted instances to 
 be a materialized part of the containing instance.

 If you are referring to what the data instance structure looks like, 
 yes

regular expressions

2013-09-23 Thread Bert Verhees

I have a question about the ADL-parser concerning the the 
regular-expressions.

I checked page 65 in:
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf

Can someone please explain why this fails:
value existence matches {1..1} matches {/[0-9]{1,8}/}

Error:
se.acode.openehr.parser.ParseException: Encountered  / /  at line 
186, column 57.
Was expecting:
 } ...

Thanks very much

Bert Verhees

regular expressions

2013-09-23 Thread Bert Verhees

On 09/23/2013 01:29 PM, Diego Bosc? wrote:
 It should work, it is valid ADL

It works, I was using an older adl.jj, I updated it, and now it seems to 
work.

Sorry for the trouble

Bert


 2013/9/23 Bert Verhees bert.verhees at rosa.nl 
 mailto:bert.verhees at rosa.nl

 I have a question about the ADL-parser concerning the the
 regular-expressions.

 I checked page 65 in:
 http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf

 Can someone please explain why this fails:
 value existence matches {1..1} matches {/[0-9]{1,8}/}

 Error:
 se.acode.openehr.parser.ParseException: Encountered  / /  at
 line 186, column 57.
 Was expecting:
 } ...

 Thanks very much

 Bert Verhees



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/d23096f5/attachment.html

Polishing node identifier (at-codes) use cases.

2013-09-20 Thread Bert Verhees

Op 20-9-2013 17:01, Thomas Beale schreef:
 it's simpler than you think - we made that property mandatory so that 
 programmers would never get a null exception.
Must have been along time ago, nowerdays, programmers have no problem 
handling a null property.

I wonder what the idea behind stuffing the archetype_id in the 
archetype_node_id property is?
Here you make it harder for programmers because the archetype_id has 
another syntax in archetype-paths then the archetype_node_id has, and 
anyway, lots of other functions, and a programmer has to check the 
string-layout to find out if it is an archetype_id or an 
archetype_node_id. It also blocks the possibility to store the at-code 
for the root, and check the ontology for its contents.

Bert

Path in use_node

2013-09-05 Thread Bert Verhees

On 09/05/2013 09:38 AM, Diego Bosc? wrote:
 II would say that you just have to attach the remaining path from 
 target node to the use_node path, so I would say first option is the 
 right one

That seems to me the most logical too.

Thanks, Diego!

Bert




 2013/9/5 Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at 
 rosa.nl

 Hi All,

 We had a discussion about data-pointds being identified by
 archetype-path, not  archetypenode-id.
 I agree with that, but I am a bit confused how to do following.

 consider following fantasy archetype

 --

 Entry[at] matches {-- Encounter
 attribute1 matches {
 SECTION[at0003] occurrences matches {0..1} matches {
 items  cardinality matches {0..*} matches {
 ITEM_LIST[at0007] occurrences matches {0..1}
 matches {
 items existence matches {0..1} cardinality
 matches {0..*; unordered; unique} matches {
 ELEMENT[at0008] occurrences matches
 {0..1} matches {
 value matches {
 DV_TEXT occurrences matches
 {1..1} matches {
 value matches {/abc/}
 }
 }
 }
 }
 }
 }
 }
 }
 attribute3 matches {
 use_node ITEM_LIST /attribute1[at0003]/items[at0007]
 }
 attribute4 matches {
 use_node ITEM_LIST[at0005]
 /attribute1[at0003]/items[at0007]
 }

 --

 Now I want to know the path in the three ways to the data-point of
 value of DV_TEXT

 Which one is right, or are all wrong?

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0008]/value/value
 [archetype_id]/attribute4[at0005]/items[at0008]/value/value

 or we have this (repeat the targetpath also in the path to the
 data-point)

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute4[at0005]/items[at0007]/items[at0008]/value/value

 or is it like this (repeat the complete path of the targetpath)

 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 
 [archetype_id]/attribute3/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 
 [archetype_id]/attribute4[at0005]/attribute1[at0003]/items[at0007]/items[at0008]/value/value

 Thanks very much

 Bert



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130905/e1bdc753/attachment.html

Path in use_node

2013-09-05 Thread Bert Verhees

On 09/05/2013 10:57 AM, David Moner wrote:
 At the first use_node reference you have to add the target node_id 
 at0007. You don't have to repeat the items container attribute at 
 the path, which is substituted by attribute3, but the target node id 
 has to be used if it is not redefined by a new one, as in the case of 
 attribute4[at0005]

 [archetype_id]/attribute3[at0007]/items[at0008]/value/value

Yes, I think you are right, David, that seems logical too.
I think you say this because the nodeId of the first following RMObject 
needs to be added, and that is in that case, if not overwritten by the 
use_node, the nodeId in the targetpath.

Thank you very much
Bert


 2013/9/5 Bert Verhees bert.verhees at rosa.nl mailto:bert.verhees at 
 rosa.nl

 On 09/05/2013 09:38 AM, Diego Bosc? wrote:
 II would say that you just have to attach the remaining path from
 target node to the use_node path, so I would say first option is
 the right one

 That seems to me the most logical too.

 Thanks, Diego!

 Bert





 2013/9/5 Bert Verhees bert.verhees at rosa.nl
 mailto:bert.verhees at rosa.nl

 Hi All,

 We had a discussion about data-pointds being identified by
 archetype-path, not  archetypenode-id.
 I agree with that, but I am a bit confused how to do following.

 consider following fantasy archetype

 --

 Entry[at] matches {-- Encounter
 attribute1 matches {
 SECTION[at0003] occurrences matches {0..1} matches {
 items  cardinality matches {0..*} matches {
 ITEM_LIST[at0007] occurrences matches
 {0..1} matches {
 items existence matches {0..1}
 cardinality matches {0..*; unordered; unique} matches {
 ELEMENT[at0008] occurrences
 matches {0..1} matches {
 value matches {
 DV_TEXT occurrences
 matches {1..1} matches {
 value matches {/abc/}
 }
 }
 }
 }
 }
 }
 }
 }
 attribute3 matches {
 use_node ITEM_LIST /attribute1[at0003]/items[at0007]
 }
 attribute4 matches {
 use_node ITEM_LIST[at0005]
 /attribute1[at0003]/items[at0007]
 }

 --

 Now I want to know the path in the three ways to the
 data-point of value of DV_TEXT

 Which one is right, or are all wrong?

 
 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0008]/value/value
 [archetype_id]/attribute4[at0005]/items[at0008]/value/value

 or we have this (repeat the targetpath also in the path to
 the data-point)

 
 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 [archetype_id]/attribute3/items[at0007]/items[at0008]/value/value
 
 [archetype_id]/attribute4[at0005]/items[at0007]/items[at0008]/value/value

 or is it like this (repeat the complete path of the targetpath)

 
 [archetype_id]/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 
 [archetype_id]/attribute3/attribute1[at0003]/items[at0007]/items[at0008]/value/value
 
 [archetype_id]/attribute4[at0005]/attribute1[at0003]/items[at0007]/items[at0008]/value/value

 Thanks very much

 Bert



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org  mailto:openEHR-technical at 
 lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 mailto:openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 -- 
 David Moner Cano
 Grupo de Inform?tica Biom?dica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es
 http://www.linkedin.com/in/davidmoner

 Universidad Polit?cnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8

concerning adl-parser

LinkEHR writes an archetypenode id in a use_node, the Java ADL-parser 
regards this as erroneous, although it is permitted in the AOM, where 
there is an nodeId in the ArchetypeInternalRef constructor.

The repair in adl.jj was, however simply to do. I tested it with all 
available testfiles, and also with adding an nodeId in the 
adl-test-entry.archetype_internal_ref.test-arc hetype, like this:

attribute3 matches {
 use_node SECTION /items[at0001]
 use_node SECTION /items[at0002]
 }
 attribute4 matches {
 use_node SECTION[at0005] /items[at0001]
 use_node SECTION[at0006] /items[at0002]
 }

I copied the needed code-change down below:

ArchetypeInternalRef archetype_internal_ref(String path, CAttribute 
parent) :
{
   String type;
   IntervalInteger occurrences = new IntervalInteger(1, 1);
   String target;
   String nodeID = null;
}
{
   SYM_USE_NODE type = type_identifier()
[ nodeID = constraint_ref() ]
[ occurrences = c_occurrences() ]
   target = absolute_path()
   {
   return new ArchetypeInternalRef(path, type, occurrences, nodeID, 
parent,
   target);
   }
}
---
Also, I mentioned another problem in the ADL-parser last week, but I got 
no feedback on that, it was maybe because it was a bit confusing.

Again, below the description and how to change the code:

The ADL-Parser is not capable of parsing EN13606 archetypes because of 
the keyword units which belongs to the EN13606 datatype PQ.

I solved this problem by commenting out all occurrences of SYM_UNITS

This is in line 2958, becomes:
CDvQuantityItem c_dv_quantity_item() :
{
   Interval value = null;
   Interval precision = null;
   String units;
}
{
   [ string_value() ] SYM_EQ 

 (SYM_C_QUANTITY_UNITS) SYM_EQ 
   units = string_value()
 

 [
   SYM_MAGNITUDE SYM_EQ 
 value = real_interval_value()
   
 ]

 [
   SYM_PRECISION SYM_EQ 
 precision = integer_interval_value()
   
 ]
   
   {
   return new CDvQuantityItem(value, precision, units);
   }
}

and line 341 containing: |  SYM_UNITS: units :DOMAIN_TYPE_C_QUANTITY
is removed
--
I don't know if it is wished that both issues which are repaired this 
way will be posted in the according repository.
If so, I can post the change.

If not, it works for me.

Thanks
Bert

date-time pattern

I have received a few archetypes created with the LinkEHR editor.

In there is a dateTime pattern like this:
time existence matches {1..1} matches {-??-??T??:??:??}

I wonder if it is a legal pattern according to the specifications. I 
must say that it is an EN13606 archetype.

If it is legal, then we (or me) need to change the Java-software, 
because at this time, it does not accept this pattern.

se.acode.openehr.parser.ParseException: Encountered  ? ?  at line 
200, column 136.
Was expecting:
 } ...

 at 
se.acode.openehr.parser.ADLParser.generateParseException(ADLParser.java:7258)
 at 
se.acode.openehr.parser.ADLParser.jj_consume_token(ADLParser.java:7122)
 at se.acode.openehr.parser.ADLParser.c_attribute(ADLParser.java:2801)
 at 
se.acode.openehr.parser.ADLParser.c_complex_object_body(ADLParser.java:2578)
 at 
se.acode.openehr.parser.ADLParser.c_complex_object(ADLParser.java:2561)
 at se.acode.openehr.parser.ADLParser.c_object(ADLParser.java:2606)
 at se.acode.openeh

Can someone please comment on this?

Thanks in advance
Bert

date-time pattern

On 09/02/2013 03:17 PM, Diego Bosc? wrote:
 I think we changed this somewhere in the past. Now we only allow date 
 as -mm-dd or -??-?? and times as hh:mm:ss, hh:mm:?? or 
 hh:mm:XX (as we haven't been able to find use cases for the all 
 question marks dateTime).

 Having said that, LinkEHR parses -??-??T??:??:?? but it is 
 interpreted as -??-??
Ahhh,  thanks, that saves me a lot of trouble. :)
I change the archetypes accordingly

 We are preparing a new version of LinkEHR lite with all these changes

please make it also 64 bit for Linux, I cannot get to run a 32 bits JVM 
on my machine, and I am afraid if I try too hard, maybe nothing will run 
after that :(


Bert

concerning adl-parser