Release 1.0.1 candidate XML-schemas online

Technical (archive)
1

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.
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

2

Just some minor nits

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

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

Andrew

3

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

4

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

5

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