Mattias,
Sorry, I didn't realise this schema was available (I overlooked your
reference to it in your original email). OK, so based on this schema the
instance is similar to my second example (but using children as the element
name rather than members) and your first example, which neither of us like
due to the plural nature of the element name for a singular element. I
think we need to pass this feedback on to Sam and see if we can ensure that
the schema fully reflects the Reference Model including element names that
reflect model attribute names such as members and existence.
The usual way a list is represented is a container with multiple items, this
is how I came up with this representation of a members element with item
child elements. You are right in stating that this is not in the XML schema
or AOM, I was looking at this from first principles.
Looking deeper into how the openEHR RM XML schemata represent containment, I
find that it has used the pattern suggested in the Archetype XML schema.
For example SECTION has element called items that is repeatable. I guess we
need to continue with that pattern unless we change the openEHR RM XML
schemata as well. The problem with changing this is that the openEHR paths
are designed to be compatible with XPath and converting a path such as
/content[openEHR-EHR-SECTION-findings.v1]/items[openEHR-EHR-OBSERVATION-labo
ratory.v1] into XPath and evaluating it will expect to have an XML element
called items within an element called content.
Therefore I suggest that based on the current XML schema your instance
should look like your first example:
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...
<children xsi:type="C_COMPLEX_OBJECT">...</children>
<children xsi:type="C_COMPLEX_OBJECT">...</children>
</attributes>
However, I would advocate that we should submit a change request to change
the schema to use the element name of members rather than children. There
are probably other AOM alignments required.
Additionally I would like to see the use of an existence element of type
INTEGER_INTERVAL (i.e. INTERVAL<integer>) rather than minOccurs & maxOccurs.
Thoughts?
Heath
_____
From: [email protected]
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Mattias Forss
Sent: Friday, 17 November 2006 4:44 PM
To: For openEHR technical discussions
Subject: Re: XML serializer (retry due to too large message)
Hi Heath,
I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in
the AOM (since I know the AOM very much in detail), but it's not in the XML
schema specification. I have not followed the AOM, because I thought I was
only supposed to look at the schema. Here's the XML schema and XML instance
of C_MULTIPLE_ATTRIBUTE with the property 'children' and not 'members' as in
the AOM:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishi
ng/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html
<http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish
ing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html> . If
you could explain a bit more which strategy I should use when generating XML
instances I would be very grateful. It seems you suggest I should follow the
AOM more closely instead of the XML schema of AOM and its instance
representations.
By the way, your second example representation of 'members' is similar to
Andrew's example and not mine. I have one container element called
'children', but no xsi:type specified. Where do you get the <item> element
name from? I can't find it neither in the XML schema nor the AOM.
Regards,
Mattias
2006/11/17, Heath Frankel <heath.frankel at frankelinformatics.com>:
Mattias,
You don't seem to follow the AOM when generating your XML instances. For
example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is
a list of C_OBJECT. This property name should be used in the XML instance
so you would get:
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">
<members>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
</members>
</attributes>
The alternative is to have the following but I suggest that members is not
quite right similar to your use of children below.
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">
<members xsi:type="C_COMPLEX_OBJECT">...</members>
<members xsi:type="C_COMPLEX_OBJECT">...</members>
</attributes>
I would also suggest that we should follow the AOM more closely and use an
existence element rather than minOccurs and maxOccurs. What you are doing
by using the later is mimicking ADL rather than following the AOM.
Therefore you would get by following based on the openEHR RM for the
Interval type.
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE">
<existence>
<lower xsi:type="xs:int">1</lower>
<upper xsi:type="xs:int">1</upper>
...
</existence>
<members>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
<item xsi:type="C_COMPLEX_OBJECT">...</item>
</members>
</attributes>
Regards
Heath
_____
From: [email protected] [mailto:
<mailto:openehr-technical-bounces at openehr.org>
openehr-technical-bounces at openehr.org] On Behalf Of Mattias Forss
Sent: Friday, 17 November 2006 8:16 AM
To: For openEHR technical discussions
Subject: Re: XML serializer (retry due to too large message)
Hi Andrew,
I looked at your example and I think it could be a good way to use xsi:type
to indicate sub-types where the number of children elements are specified to
be only one. This will mean that we don't need to add an extra sub-element,
e.g. <description xsi:type="RESOURCE_DESCRIPTION"> (details here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishi
ng/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html).
However, I don't think the XML schema specification of the AOM explicitly
state that xsi:type should be in XML archetypes. I would appreciate if
openEHR published some XML archetypes that exemplified the standard way to
express them. I don't like the idea of having several ways of representing
archetypes in XML so it would be nice if some examples were out to lead the
way.
When there are more than one child inside an element, the idea with xsi:type
requires us to repeat the container element for each child instead of
placing all children inside a single container element, so you have
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...
<children xsi:type="C_COMPLEX_OBJECT">...</children>
<children xsi:type="C_COMPLEX_OBJECT">...</children>
</attributes>
instead of
<attributes xsi:type="at:C_MULTIPLE _ATTRIBUTE" minOccurs="1" maxOccurs="1">
...
<children>
<C_COMLEX_OBJECT>...</C_COMPLEX_OBJECT>
<C_COMLEX_OBJECT>...</C_COMPLEX_OBJECT>
</children>
</attributes>
The first example is of course more compact, but the element name "children"
doesn't make sense, since it doesn't contain all of the attribute's
children. The second example will collect all the children in one single
container element, but again, I don't know what the specification mean with
the occurrences brackets, e.g. what does [0..*] refer to in <children>
C_OBJECT
<http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publish
ing/its/XML-schema/documentation/Archetype.xsd.html_h-1665829344.html>
</children> [0..*] ? Does it refer to the <children> element or to the
C_OBJECT element? This should be clarified. I have been dealing a lot with
ADL and I can say that the second example seems more plausible to me and I
see the children element equal to an attribute's "matches {}" in ADL.
Any thoughts about this?
Regards,
Mattias
2006/11/16, Andrew Patterson <andrewpatto at gmail.com>:
Hi Mattias, I've attached my attempt at a serialized adl instance - perhaps
we can converge on a consensus as to what they should look like!
Mine is incomplete - especially around the ontology section - but I have
done the attributes and children nodes differently, using xsi:type to
indicate the sub-type. This is similar to the way Sam did the reference
model serializations I saw, so I thought similar techniques would be
applied here.
Anyhow, I'm off on another project for a few weeks, but I thought I'd
send you this instance as food for thought.
Andrew
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
<http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/9c964e43/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
