Adam Flinton wrote:
> Peter Gummer wrote:
>
>> Adam Flinton wrote:
>>
>>
>>
>>> I have already noted how using text children of an element to use a value
>>> vs a std "value" attribute in the archetype xml inflates the file sizes.
>>>
>>>
>> So you aren't convinced by Thomas's objection that putting the values in XML
>> attributes would make a mess of the XPath?
>>
>>
>
> No as the existing paths aren't xpaths at all e.g..
>
> <Rule path="/items[at0001]/items[at0004]" max="0" />
>
> let alone something like
>
> <excludedValues>local::at0013</excludedValues>
>
> It's simply a matter of parsing the file into an AOM.
>
>
Adam,
I was not talking about openEHR paths, I was talking about any Xpaths.
If you define an Xpath based on a given model entity being an XML
attribute, it will be different from the path to the same thing based on
the model entity being an XML element. If that path was shared, e.g. in
a tool, or published for some reason, and you change your XML
representation for efficiency reasons, your published Xpath doesn't work
any more.
Separately, in openEHR, we use Xpath-compatible paths. A path like
/items[at0001]/items[at0004]
is machine converted to the Xpath
/items[@archetype_node_id = "at0001"]/items[@archetype_node_id =
"at0004"]
Not hard to guess why we do that;-)
Portable paths are the basis of portable queries; portable queries are
the basis of decision support having any hope of being able to define
queries once and for all into a standardised health record rather than
havig to have queries written not just for each target system type, but
for each installation, if database schemas differ (and they do in the
NHS environment).
- thomas beale
*
*
