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/publishing/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:* openehr-technical-bounces at openehr.org [mailto: > 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/publishing/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/publishing/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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/4d945f53/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
