Sounds like the Java XML generator needs to be corrected to never spit
this out then. This should be straightforward to fix.
I wonder however if this is just in there by mistake and nobody ever
cared before that this fairly frequent case breaks the schema or if
there was some kind of hidden use case for this.
Sebastian
On 28.03.2012 19:16, Thomas Beale wrote:
> On 28/03/2012 16:44, Sebastian Garde wrote:
>>
>>
>> On 28.03.2012 14:47, Athanasios Anastasiou wrote:
>>> Hello everyone
>>>
>>> I keep getting an error when parsing this ecg archetype (expressed
>>> as XML) and i was wondering if this could be because the archetype
>>> was uploaded to the CKM when the CKM used a different version of the
>>> published openEHR XSDs, if this used to be a bug of the archetype
>>> editor or if it could be something that i am doing wrong.
>> No - the xml in CKM is produced on the fly from the adl, so it is
>> always up to date...
>> But of course not necessarily always correct: There may well a bug in
>> the generation process of the Java XML generator,
>> but can someone say definitely if the any_allowed tag should be in
>> the xml or not, first?
>> (any_allowed is an operation, not an attribute in the constraint model)
>
> ADL example:
>
> DV_TEXT matches {*} -- object case
>
> or
>
> value matches {*} -- attribute case
>
> In the AOM it is computed to be True if...
>
> * in a C_ATTRIBUTE there are no children
> * in a C_COMPLEX_OBJECT there are no children
> * in a C_PRIMITIVE_OBJECT, there is no 'value', i.e. no attached
> C_PRIMITIVE (parent type of C_DATE, C_INTEGER etc etc)
>
> I would also expect it to be computed from the XML, since the XML is
> based in the AOM.
>
> - thomas**
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120329/42b30f6c/attachment.html>
