The XML generator had a comment "not sure if needed" next to the
any_allowed related code.
So I have removed this now.
A corrected version is deployed to the openEHR ckm.
Regards
Sebastian
On 29.03.2012 08:49, Sebastian Garde wrote:
> 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/b32d7284/attachment.html>
