I have been doing some tests with the file archetype.xsd available on
the webpage and I have run with some problems.
The main one is regarding BaseTypes.xsd, which supposedly defines
types such as intervalOfInteger, intervalOfDate..., but doesn't
contain them. Documentation
(http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/documentation/BaseTypes.xsd.html#h888547087)
says otherwise, so I'm not sure how are documentation and schema
generated/related.
I suspect that schema is out of date, but I don't quite understand how
a supposedly autogenerated documentation and his XSD disagree. I know
that this kind of approach is being left behind, but at least a
version public on the webpage should be complete (take note that I'm
not talking about being correct regarding the specifications, for the
moment I just want to compile it)
Another thing I have detected is a mix of CamelCase and underscores on
the types definition of current BaseTypes.xsd. There are things like
DATA_VALUE or DV_DATE_TIME but also archetypeNodeId, atCode, or
Iso8601DateTime.
ok, then the link of the XSD is pointing to an old version (link on
this page http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/index.html).
This is the page that can be reached through the openEHR website menu.
and the second issue is still true: types with CamelCase and
underscores names exist on the same schema
What is the issue? The upper case types defined in the logical
specifications, whilst the CamelCase are ITS defined. Like many mappings
from logical specifications to an implementation technology, the XSD is not
a pure representation of the logical specification. At least using this
mixed approach it is obvious which are which.
If you are concerned about this because you are generating classes from the
schema, then this is the price you pay unfortunately. It is impossible to
represent the logical specifications in its entirety using XSD, however it
does provide you with a pretty good serialised representation of the
specified models, these types do not appear in XML instances.
Having said that, it is likely that the XML schema will be reviewed in the
near future as part of ADL 1.5 release and we are considering the pros and
cons of various XSD representations based on human readability,
specification alignment, class generation etc. You may want to contribute to
this when it gets underway.
It is not 'wrong', I'm just saying that following the same syntax for
everything would be better. We had already a discussion about this on
this same list regarding same issues on other schema. I was just
pointing them out in case they need to be changed.
ok, then the link of the XSD is pointing to an old version (link on
this page [http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/index.html](http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/index.html)).
This is the page that can be reached through the openEHR website menu.
you are right, the TRUNK page text was out of date. No new XSDs have been uploaded yet. I am working on a new AOM xsd. For the RM, there are various suggestions for improvement, and I think anyone who has improved versions to proposed, please post them on the wiki with some documentation, and we will link from the above page.
and the second issue is still true: types with CamelCase and
underscores names exist on the same schema
well that’s life in XML schema land. It may offend some from a pure aesthetics point of view, but it is actually more helpful than harmful, because it makes it easy to recognise XSD class definitions that are ‘pure’ copies of the RM, versus pseudo-classes needed due to XSD limitations. This is very useful for software implementation…
despite my last comment (that the differing upper-case & mixed-case in
the same schema is useful), if the community wants to change this to
just camel case, that's fine. I personally would argue against it for
the reasons I gave, but that's just my opinion; the opinions of people
buried in XML implementations are more important.