# Release 1.0.1 candidate XML-schemas online

**URL:** <https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634>\
**Category:** Technical (archive)\
**Created:** [26 March 2007 12:18 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634 "2007-03-26T12:18:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [26 March 2007 12:18 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634/1 "2007-03-26T12:18:34Z")

</div>

Dear all,

the latest drafts of the Release 1.0.1 XML schemas are now online - see  
[http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/its/XML-schema/index.html](http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/its/XML-schema/index.html).  
There are still some details to be fixed on this page, but we believe  
the schemas are close to correct. Feedback welcome.

Thanks to Chunlan Ma and Heath Frankel for working on these, and to  
Mattias Forss, Andrew Patterson and others here for their continued  
feedback.

- thomas beale

---

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [27 March 2007 03:50 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634/2 "2007-03-27T03:50:12Z")

</div>

Just some minor nits

1) comment in Composition.xsd regarding 'limited to one in the current schema'  
&nbsp;&nbsp;&nbsp;&nbsp;doesn't seem to apply anymore so should be removed

2) whilst the capitalization isn't significant on windows machines, resource.xsd  
&nbsp;&nbsp;&nbsp;should probably be renamed to Resource.xsd for consistency and all  
&nbsp;&nbsp;the xsd:import statements should be consistent in their use of the  
correct case.

Andrew

---

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [27 March 2007 06:41 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634/3 "2007-03-27T06:41:00Z")

</div>

Another request, because the XML schemas are  
artifacts that need to be kept in sync with a  
non machine processable document (the AOM doc etc),  
it would be great if the order of elements within the  
XML schema types matched the order within the  
documents. It makes it a lot easier to check the  
correspondence by hand. Now I don't know if that  
means we should reorder the elements in the document,  
or reorder the elements in the schema - but it would be  
good if we had a consistent rule that XML schema order  
matches the order in the document.

So for instance, ARCHETYPE should have elements  
adl\_version, then archetype\_id, then uid etc.. at the  
moment, the order in the schema is essentially  
arbitrary.

Andrew

---

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [27 March 2007 06:47 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634/4 "2007-03-27T06:47:11Z")

</div>

C\_REFERENCE\_OBJECT seems to be missing  
from Archetype.xsd - it doesn't do much but it is  
in the AOM so it should have a corresponding definition  
in the xml schema.

Andrew

---

<div class="post-metadata">

**Author:** ![Heath\_Frankel](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/h/c4cdca/32.png) [@Heath\_Frankel](https://discourse.openehr.org/u/Heath_Frankel)\
**Post date:** [27 March 2007 08:07 UTC](https://discourse.openehr.org/t/release-1-0-1-candidate-xml-schemas-online/14634/5 "2007-03-27T08:07:53Z")

</div>

Andrew,  
There was an early design decision made to skip abstract classes with no  
class attributes because they add no data and will never have instance of  
that type. The schema is an ITS of the specifications and does not need to  
be a mirror, as long as they are consistent and produce the same outcome.  
This is consistent throughout the AM and RM classes except for  
C\_DOMAIN\_TYPE. This was kept due to it being like a slot for RM archetype  
profile constraint classes such as C\_DV\_QUANTITY.

Regards

Heath