Seref Arikan wrote:
Hi Adam,
I would be very interested to hear about the problems you've
identified. Would it be possible to get an overview of problems? For
example, what is it that makes you consider use of regex'es as a
problem? Is it a functional problem or a performance related issue?
What are others, if there are any?
I think having a list of issues/bugs etc regarding the java ref. impl
and tooling would be very valuable. As far as I know there is no such
list at the moment.
A) The problems are more at an archetype level per se.
It was to do with the regex in the archetype locators not being full
regex'es i.e. no inclusion of the rm_type name.
What it meant was that when ID'ing another archetype you had to go up to
it's rm_type name & then concat that with the regex etc to arrive at the
"real" regex. Which was a bit of an annoyance. It is one of the things
which is fixed in the nitrogen release.
We still have to support both sorts as once published we can not change
final versions of anything so a partial XSLT listing :
<xsl:template name="ArchetypesMatchRegexPattern">
<xsl:param name="p_pattern" />
<xsl:param name="p_rootNode" />
<xsl:param name="p_rm_type_name" />
<xsl:param name="debug" />
<!-- openEHR-EHR-CLASS_NAME\.(REGEX_EXPRESSION) -->
<!-- When $p_pattern contains $p_rm_type_name assume it is a full regex
Else assume an (old) partial regex
-->
<xsl:variable name="v_Dotpattern" >
<xsl:choose>
<xsl:when test="contains($p_pattern,$p_rm_type_name)">
<xsl:message>
ArchetypesMatchRegexPattern NEW STYLE
</xsl:message>
<xsl:value-of select="$p_pattern" />
</xsl:when>
<xsl:otherwise>
<xsl:message>
ArchetypesMatchRegexPattern OLD STYLE
</xsl:message>
<xsl:value-of
select='concat(normalize-space($p_rm_type_name),"\.(",normalize-space($p_pattern),")")'
/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
B) However.....since you asked ....<G>
I created 2 ant tasks one using the Java Impl to create XML Archetypes
from ADL & another using the Ocean Windows/.net code & it was
interesting that some had some structures & others others & that the
Java one seemed more exacting (e.g. erroring on a lack of an original
author).
However my main problem was to do with the actual XML representation per
se as in it's current form it is undiffable (I was looking to run both &
then diff the 2 XML outputs from the same ADL). I.e. to work out that
the java impl was creating some structures which the Ocean one wasn't I
had to do a lot of "by eye" checking which is not very precise.
IMHO the Archetype XML format needs a deep level redo & this becomes
painfully apparent when one tries using the newest Template tools as
when you create operational templates the XML is perfectly OK at the
template level but then it includes the relevant Archetype XML & the
experience is jarring.
i.e. the current format is fine for creating an entire object but if one
wants to use it as a deliverable (especially one where implementors will
want to check over it looking for differences from a previous version)
then.....
or indeed if one wants to use the Java ADL > XML to check the .Net ADL >
XML or vice versa as (for example) there is no order of elements or sort
order etc so the exact same object could be persisted to XML entirely
correctly by 2 implementations & the XML would look entirely different
(e.g. big structure A followed by big structure B in one impl vs the
opposite in another & within each structure this same variability is
then repeated).
It is a mindset change i.e "this is simply a persistence mechanism for
an archetype object" vs "this is a document/deliverable which I will
need to compare at a document level with other versions of this
archetype at a document level".
i.e. given the same ADL I would expect identical XML outputs (identical
in XML terms e.g attribute order might change) no matter what the engine
was which created it.
Adam
