Tom,
Re: the archetype/runtime path shortcut, in discussions with Sam we
came to the conclusion that these predicates would always be
associated with the name attribute and that having a predicate like
/identities[at0001 and name/value="alias"] is rather verbose,
especially when you have a full path
TB: I am not convinced by this - there will definitely be predicates
referring to attributes other than the name attribute..
Ok, for more general queries yes, for ItemAtPath it will "normally" be
archetype_node_id and name/value. So a shortcut for this combination would
be useful. All other attributes can still be done in long-hand.
going through sections, entries, events where you end up with 3 or 4
predicates in one path it is just not workable.
TB: It's just longer isn't it?
Yeah, long than the width of the screen (well pretty close :>)
I know you would say that
these are not intended for humans and only for computers but they say
that about XML and that one of the favourite topics of techies is to
argue the XML form of some data.
TB: but a query-building tool will mean that humans indeed never see
this...or not often (I think paths are more or less readable, in a little
path-editing tool, just as XML becomes readable when you strip the garbage
and present it nicely).
Developers will still work with them, designers may not (or shouldn't have
too), just like XML.
Additionally, there will be humans working with these, and I and my
team have been for several months for several artefacts including
Queries, Templates and Feeder System mappings. Sure this will be
reduced as tooling support is increased but there will always be some
that will want to work with a path or perhaps even displaying one within a
tool.
Our Feeder Source Mapping Tool currently works by displaying paths and
some don't fit on a 1024x768 screen, that's scary!
TB: do you mean if they are shown as a single line of text? I think that's
just a case of a simple path display tool...
We will use paths all over the place, most of the Ocean tools developed so
far use them and display them on one line. We have one that has a path in a
column of a grid with another 5 or so columns including one that contains an
XPath expression as well. Pretty hard to display a path in a grid without
doing it in one line. Then we have a tool tip pop up to display the whole
path because you can't see more than the first predicate and it extends past
the bounds of the screen/ You don't have much control over some of these
existing GUI components.
Anyway, if the conclusion that the runtime paths will not always be
the name and there is an exception to that rule for certain classes, I
am sure we could still use the [archetype_node_id, "key"] shortcut if
we standardise the key attribute on each class. My vote is certainly for
name everywhere.
The question I have, is this combination of archetype/run-time path legal?
TB: well, there are no "archetype" and "run-time" paths any more in any
syntax sense - it's all just the one syntax; it's just that the predicate is
longer for runtime data. I'll have to review the documentation to see if it
makes this clear enough...
Perhaps I need to re-read the latest but the last candidate version I read
still talked about archetype paths and run-time paths. In fact looking the
latest on SVN, I see section 11.2.2 discussing Predicate Expressions and
then section 11.2.4 Runtime Paths and Uniqueness. At least in the former
you do talk about archetype and run-time predicates (mainly for query
purposes) but in the later you only talk about using name/value to ensue
uniqueness (except for integer positions).
BTW, you suggest in your examples that the combinatorial expressions use an
uppercase 'AND'. In XPath only a lowercase 'and' is legal, at least in the
XML tools I use. I suggest openEHR paths should be consistent with XPath
here.
Heath
