(I leave this notice so people understand the torture I went through, while replying to this email)
Hi Bert,
Sorry but I struggled to understand the issue you have below. Would you mind looking at my comments below and see if I have understood them correctly?
Heath
In the Structure.xsd I find this line, I don’t know why it is there.
<xs:element name=“items” type=“LOCATABLE”/>
I commented it out, and it still validates fine.
[HKF: ] What did you comment out, the entire element?
that line is the complete and only global element in this file, and I commented that out, but I added global elements in this file for every type-construct representing a concrete class.
Although this is not necessary when you have a composition instance, if you want to serialize an ITEM_STRUCTURE as a root of an XML document perhaps for a query result or internal application purposes then this gives you a standard schema element to do this. If you don’t use it then commenting out will not hurt. What is the problem with its existence?
I don’t think you should serialize an item_structure as root because it is abstract. There can never be an XML instance of item_structure, and XML Schema’s are to define and validate XML instances and their appearance.
Of course I can comment it out if I want, I can do whatever I want, but I want to conform as much as possible to the OpenEhr specs, even if I do not always agree.
That is why I bring it to discussion, that is why I am glad that the XSD is formally maintained by the foundation, as Seref and Sam indicate.
There were some more things in the same file.
There were no element-declarations to the concrete classes, like ITEM_TREE, CLUSTER, and so on.
[HKF: ] The element above is used for all these subtypes____.
I am afraid that I don’t understand how that works.
In my opinion, there must be an global element declaration for every class which can be used as root. This is what I suggested as alternative for this construct which I don’t understand. For all the classes derived from item_structure, there is no global element defined.
It would be nice to have elements in the base-types XSD too. There is no need for it in the OpenEHR implementation, because they will never be root-element, but it is good to see their XML-structure isolated, for convenience.
[HKF: ] Are you talking about DATA_VALUE types or everything? Personally I don’t see the value it would add overhead n the in memory schema objects used for validation.
There you have a good point, I suggested that also, although, I think the overhead is minimal. It was just for convenience that I did my suggestion and XML schema’s are not for convenience.
So, I think your position in this is reasonable. Let’s forget point 3.
And the last point is, I missed the Demographics.xsd, although these
RM-classes are also archetypeable and can lead too to XML-instances.
[HKF: ] Yeah, I guess that shows t____he EHR focus of the specs. I also have a schema that could be used, I may have already put it up in Jira.
The specs have demographics defined, so, in my opinion, the demographics XSD should be there.
Do you mean, in your last comment, that you put it in Jira, and that that demographics XSD will arrive?
Thanks for your reply
Bert
