XML serializer (retry due to too large message)
Sam, It is only safe if the attributes are primitive types. However I think it would be a good saving considering the current attributes. Heath _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Tuesday, 21 November 2006 11:09 PM To: For openEHR technical discussions Subject: Re: XML serializer (retry due to too large message) Hi We can add more attributes safely.which I think is all that could be done without changing the model in a major manner, Sam Mattias Forss wrote: 2006/11/21, Sam Heard sam.heard at oceaninformatics.biz: The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all. What do others think? Sounds like a good idea as long as the two parts (text, description) of the description items will remain. If more parts are added though, it is not a flexible solution. Mattias Cheers, Sam _ ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. http://www.oceaninformatics.biz/ Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061122/41d71116/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
2006/11/21, Sam Heard sam.heard at oceaninformatics.biz: The Ontology is so huge I have wondered about having the Text and Description as attributes - it would save a lot of space and I do not think it would complicate things at all. What do others think? Sounds like a good idea as long as the two parts (text, description) of the description items will remain. If more parts are added though, it is not a flexible solution. Mattias Cheers, Sam -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061121/83340f4a/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061121/9849d020/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
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:int1/lower
upper xsi:type=xs:int1/upper
...
/existence
members
item xsi:type=C_COMPLEX_OBJECT.../item
item xsi:type=C_COMPLEX_OBJECT.../item
/members
/attributes
Regards
Heath
_
From: openehr-technical-boun...@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/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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/88d32b2e/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] 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/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:int1/lower upper xsi:type=xs:int1/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_OBJECThttp://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
XML serializer (retry due to too large message)
Mattias, the usage of xsi:type is solely because object hierarchies are being used in the AOM. Using xsi:type allows serializers to know the type they are getting before having to parse it in.. however, even without xsi:type, your serialization would still not be correct for the xsd given (i.e. let us pretend there is only a C_ATTRIBUTE, with no subclasses). Any reference to an element of type C_ATTRIBUTE in xml should result in an xml entry named by the 'element with type C_ATTRIBUTE' i.e. 'children'. You never put type names into the actual xml instances, merely element names. And for sequences, this means repeating the xml entry name 'children' (augmented in this case by an xsi:type to help with the subclasses). Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
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. The AOM is at fault in this instance - the AOM has a field defined in C_ATTRIBUTE called 'children', and then proceeds to rename this field to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable in any OO style language or XML.. the XML schema does the correct thing and just defines 'children' in the base C_ATTRIBUTE class. I have followed the XSD exactly in my serialization.. I believe the intention is that the archetype XSD reflects the AOM model 1:1 (as much as possible). I see the archetype XSD as a formal definition of the cotnent of the AOM document. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] RE: XML serializer (retry due to too large message)
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. INTERVALinteger) rather than minOccurs maxOccurs. Thoughts? Heath _ From: openehr-technical-boun...@openehr.org [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:int1/lower upper xsi:type=xs:int1/upper ... /existence members item xsi:type
XML serializer (retry due to too large message)
2006/11/17, Andrew Patterson andrewpatto at gmail.com: 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. The AOM is at fault in this instance - the AOM has a field defined in C_ATTRIBUTE called 'children', and then proceeds to rename this field to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable in any OO style language or XML.. the XML schema does the correct thing and just defines 'children' in the base C_ATTRIBUTE class. No, it proceeds to rename this field to 'alternatives' (not attributes) and 'members'. I agree, that it's not OO style, but why isn't it implementable in XML? XML isn't OO, it's just a way of storing structured information, and the guys building the XML parsers to create the AOM objects again can probably deal with that. But since the AOM is OO I guess it wouldn't be a bad idea if the contents of the XML instances were in OO style. Mattias I have followed the XSD exactly in my serialization.. I believe the intention is that the archetype XSD reflects the AOM model 1:1 (as much as possible). I see the archetype XSD as a formal definition of the cotnent of the AOM document. 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/e9597093/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Bert Verhees schreef: Mattias Forss schreef: Well, I'm no expert on XSD since I never cared about learning it... but if I go back to your example, why didn't you use xsi:type in some places, for example: I don't know if you ever saw this site, I did, it was helpful http://www.w3schools.com/schema/default.asp (forgot ;-) Bert ___ 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/48ba7a11/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Mattias Forss schreef: Well, I'm no expert on XSD since I never cared about learning it... but if I go back to your example, why didn't you use xsi:type in some places, for example: I don't know if you ever saw this site, I did, it was helpful Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
I agree, that it's not OO style, but why isn't it implementable in XML? XML isn't OO, it's just a way of storing structured information, and the guys building the XML parsers to create the AOM objects again can probably deal with that. The use of complexType with extensions in XSD follows the OO model. So if it has a field called 'children' in C_ATTRIBUTE, that field is going to be in all in extensions - called 'children'.. if those sub classes also define a similar field, then they will have two fields. I just presumed that the AOM had a textual mistake (whilst the 'alternatives' and 'members' are more correct descriptions of the attribute, they technically are still 'children' so I don't see a problem with them having that inherited field and using it to store alternatives and members respectively). Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
go back to your example, why didn't you use xsi:type in some places, for example: description original_author item ... Is you used it here it would be: description xsi:type=RESOURCE_DESCRIPTION original_author xsi:type=hashTableStringString item xsi:type=dictionaryItem ... because there are no doubts about the actual type of 'description' (i.e. it has no subclasses), when the serialiazer gets to the 'description' node. it knows what to expect. If we had a RESOURCE_DESCRIPTION_EXTENDED complexType that was based on RESOURCE_DESCRIPTION, then we would need to use xsi:type. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
2006/11/17, Heath Frankel heath.frankel at frankelinformatics.com: The AOM is at fault in this instance - the AOM has a field defined in C_ATTRIBUTE called 'children', and then proceeds to rename this field to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable in any OO style language or XML.. the XML schema does the correct thing and just defines 'children' in the base C_ATTRIBUTE class. I have followed the XSD exactly in my serialization.. I believe the intention is that the archetype XSD reflects the AOM model 1:1 (as much as possible). I see the archetype XSD as a formal definition of the cotnent of the AOM document. Oh, so that's why I got confused why members was implemented as a method rather than an attribute, I didn't make the correlation between members and children (perhaps I should have read the words rather than just the picture :). Oops, I also missed that it was a function :-) Maybe the specs could distinct attributes, functions, etc with different coloring. In that case, the XML schema does not require a change request for this issue. I would still like to explore the use of an existence element rather than minOccurs and maxOccurs attributes. I don't see why existence and occurrences in C_OBJECT are treated differently. And then I think the interval_of_integer type should use elements lower and upper as per the Interval assumed type specified in the openEHR Support package. Agree Mattias Heath ___ 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/4c22b4b0/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: XML serializer (retry due to too large message)
2006/11/17, Bert Verhees bert.verhees at rosa.nl: Bert Verhees schreef: Mattias Forss schreef: Well, I'm no expert on XSD since I never cared about learning it... but if I go back to your example, why didn't you use xsi:type in some places, for example: I don't know if you ever saw this site, I did, it was helpful http://www.w3schools.com/schema/default.asp (forgot ;-) Yes, the tutorials by W3 schools are nice, but most often not as detailed as one might wish. //Mattias Bert ___ openEHR-technical mailing list openEHR-technical at openehr.orghttp://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ 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/b24322db/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
XML serializer (retry due to too large message)
Andrew, In your example, you have the other_contributors element even when it has no children, but the schema specification says that it's optional, i.e. other_contributors list_of_stringhttp://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-2045140803.html/other_contributors [0..1]. Shouldn't you discard that element when the list of contributors is empty? /Mattias 2006/11/16, Andrew Patterson andrewpatto at gmail.com: description other_contributors / lifecycle_stateAuthorDraft/lifecycle_state -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/f07d1cab/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
