Stream: implementers
Topic: FHIRpath test suite
nicola (RIO/SS) (Nov 18 2016 at 09:40):
@Ewout Kramer & @Grahame Grieve could you share test cases for FHIR path in a format like JSON schema for example https://github.com/json-schema/json-schema, o different implementer can test their implementations against it.
Grahame Grieve (Nov 18 2016 at 10:06):
we use xml for test cases because it does comments. See http://hl7.org/fluentpath/tests.html
Brian Postlethwaite (Nov 18 2016 at 11:08):
(and don't really want to maintain multiple formats for it, though you can write a converter for yourself if you like)
Grahame Grieve (Nov 18 2016 at 11:14):
that should be autoconvertable using standard xml --> json tools
nicola (RIO/SS) (Dec 26 2016 at 18:07):
I'm going to implement fhirpath in C for postgresql, clojure & js - could you give me links to existing grammars and we definitely need tests not only in xml, but also in json
Grahame Grieve (Dec 26 2016 at 18:22):
grammar: http://hl7.org/fhirpath/grammar.html. We don't have tests in json, but you're welcome to translate them.
nicola (RIO/SS) (Dec 26 2016 at 18:57):
http://hl7.org/fluentpath/tests.html - 404 :(
nicola (RIO/SS) (Dec 26 2016 at 19:10):
Provided grammar is too abstract - so no difference for .name and .count() , where() or .unexistingFn() :(
Bryn Rhodes (Dec 26 2016 at 19:40):
Yeah, that's on purpose, we didn't want to put function names in the grammar. The only things in the grammar are operations with syntax.
Bryn Rhodes (Dec 26 2016 at 19:42):
The tests are here, but yes, they're only in XML:
Bryn Rhodes (Dec 26 2016 at 19:42):
https://github.com/FHIR/fluentpath/tree/master/tests
Grahame Grieve (Dec 26 2016 at 20:14):
I must have a wrong path on the serer...
Grahame Grieve (Dec 26 2016 at 20:14):
no. http://hl7.org/fhirpath/tests.html
nicola (RIO/SS) (Dec 26 2016 at 20:49):
Here i've started more semantic grammar - https://gist.github.com/niquola/72f24aeaa3066c9941605adcfd2e0008
nicola (RIO/SS) (Dec 26 2016 at 22:00):
Looks ambiguous: Patient.name.given = 'Ewout' could be like Patient.name.given.concat().some($this = 'Ewout')
And again some philosophical note: a lot of features doesn't mean it's great; minimum and sufficient - does!
May be split Fhirpath into minimal-required and fancy-optional parts?
Grahame Grieve (Dec 27 2016 at 05:49):
all good languages have redundancy. ambiguity is not the same thing
nicola (RIO/SS) (Dec 28 2016 at 13:13):
Question: we have [index] syntax in fhirpath, could "index" be fhirpath expression or just integer? Because implicit context it looks like not?!
nicola (RIO/SS) (Dec 28 2016 at 16:42):
Symmetry: why | is operator, but combine (which does almost the same) is function?
nicola (RIO/SS) (Dec 28 2016 at 17:02):
Could we say that functions like empty or count always should be the last in chain?
Grahame Grieve (Dec 28 2016 at 20:53):
I think index could be an expression. I treat it as one
Grahame Grieve (Dec 28 2016 at 20:54):
probably combine is a function rather than an operator because we came to it's need later, and adding a function is easier than adding an operator
Grahame Grieve (Dec 28 2016 at 20:55):
I think empty and count are liekly to be last, but not guaranteed to be
Mario Hyland (Dec 28 2016 at 23:33):
In case those folks on this thread missed it earlier - Richard posted on the testing thread the following: Everyone,
Just wanted to let you know that a key new feature of Touchstone v3.3.x is the inclusion of support for fhirpath expression evaluation within TestScripts. The following TestScript fhirpath related elements, added for STU3, can now be defined and executed by Touchstone:
variable.expression
assert.expression
assert.compareToSourceExpression
nicola (RIO/SS) (Dec 29 2016 at 04:22):
@Grahame Grieve oh, operator vs function looks like random choice? Implicit conversions to collection and back to value also bad idea, which brings indeterminism ;(. It would be nice to have clear deterministic model as foundation for fhirpath. There is well formulated functors, applicative and monads approach to work with collection in a composable way - for example math, string and date operations could be functors http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html#just-what-is-a-functor,-really. Also take a look at reduce as more generic approach - http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html - getting paths in collections, filters, ops like count, empty etc could be expressed as reduce functions. Also we need clearly specify how implicit data context is propagated in functions - here the idea of piping and/or carrying could be used
nicola (RIO/SS) (Dec 29 2016 at 04:25):
Operators vs functions - in haskell and ocaml all functions of two arguments could be written in infix (operators) notation
nicola (RIO/SS) (Dec 29 2016 at 04:27):
So grammar quite easily could be written to enable this automatically.
nicola (RIO/SS) (Dec 29 2016 at 04:31):
We could treat dot (.) as pipe operation (if we have carrying) or macro (if not)
Bryn Rhodes (Dec 29 2016 at 19:52):
I'm not sure what you mean by implicit conversion to collection and back brings indeterminism?
Bryn Rhodes (Dec 29 2016 at 19:52):
By deterministic, I mean that the expression will give the same result every time it is evaluated.
Bryn Rhodes (Dec 29 2016 at 19:52):
How does implicit conversion to/from a list change that?
Bryn Rhodes (Dec 29 2016 at 20:25):
As far as operator vs function being a random choice, it's not random, it's based on expected usage and traditional expressions. Plus is an infix operator because that's how most people expect to be able to invoke it.
Grahame Grieve (Dec 29 2016 at 20:36):
the discussion started with a single case where we might have defined an operator instead of a function, but didn't
Bryn Rhodes (Dec 29 2016 at 20:41):
So I think in that case, (| vs combine), we defined an infix operator because we expected to be doing lots more unioninig than combining.
nicola (RIO/SS) (Dec 29 2016 at 20:49):
@Bryn Rhodes i mean indeterministic by different implementations ( i think unspecified behaviour is better word): for example you have some.expression > 2 where some expression evaluated into [1,2,3] and we got => [1,2,3] > 2 - what result should we expect?
nicola (RIO/SS) (Dec 29 2016 at 20:50):
If we always distinct list vs value operations, we could be accurate and precise: expression.some( $this > 2) or expression.all($this > 2)
Bryn Rhodes (Dec 29 2016 at 20:59):
@nicola (RIO) in that case we expect a run-time error because the ">" operator expects singleton inputs. The specification indicates that when an operator that expects a singleton input is given a collection with more than one element at runtime, that an error is thrown.
Bryn Rhodes (Dec 29 2016 at 21:01):
If you want to return only elements that are greater than 2, you use a where: expression.some.where($this > 2)
nicola (RIO/SS) (Dec 29 2016 at 21:12):
No, i mean logical operation
nicola (RIO/SS) (Dec 29 2016 at 21:15):
What about name.given = 'Smith', should it fail if given.count > 1?
Bryn Rhodes (Dec 29 2016 at 21:16):
Yes.
nicola (RIO/SS) (Dec 29 2016 at 21:18):
I mean, if we introduce explicit conversion to/from collection and forbid such type of implicit operations on collection with one item - it will be much less frustrating :)
nicola (RIO/SS) (Dec 29 2016 at 21:19):
name.given.where($this = 'Smith').exists() and name.given[0] = 'Smith'
Bryn Rhodes (Dec 29 2016 at 21:19):
So, in the CQL usage, we have defined an option to indicate whether or not those types of implicit conversions to and from lists are allowed.
Bryn Rhodes (Dec 29 2016 at 21:20):
But FHIRPath itself allows you to make that decision as part of the implementation.
Bryn Rhodes (Dec 29 2016 at 21:20):
The point being that if you as the author know that .given will only have one element, then the compiler shouldn't prevent you from expressing something that you know will work.
nicola (RIO/SS) (Dec 29 2016 at 21:23):
Bad parts of javascript is good evidence, that such decisions are evil. Let say you use such ubiquitous expression as invariant in some national profile?
Bryn Rhodes (Dec 29 2016 at 21:25):
I agree there are cases where you don't want to allow that kind of flexibility, but there are cases where you do want it too, so the specification allows the more general, and implementations can impose the more strict interpretation as necessary.
nicola (RIO/SS) (Dec 29 2016 at 21:26):
Hey, we are talking about interop :)
nicola (RIO/SS) (Dec 29 2016 at 21:26):
So fhirpath is not interoperable?
Bryn Rhodes (Dec 29 2016 at 21:27):
That's a pretty broad generalization.
Bryn Rhodes (Dec 29 2016 at 21:27):
I'm not even sure what it means. :)
nicola (RIO/SS) (Dec 29 2016 at 21:28):
Why - if some expressions could be interpreted by different implementations differently - is this interoperability? And this expressions will be in the heart of search, validation etc.
nicola (RIO/SS) (Dec 29 2016 at 21:28):
@Josh Mandel what do you think?
Bryn Rhodes (Dec 29 2016 at 21:29):
Part of using an invariant within a given environment would require that you specify the behavior so that different implementations would get the same interpretation.
Bryn Rhodes (Dec 29 2016 at 21:30):
Within the FHIR specification specifically, invariants are allowed to use the implicit conversions to/from lists, but the implementations are expected to throw when singleton expectations are violated. I don't see how that results in a spec that is not interoperable?
nicola (RIO/SS) (Dec 29 2016 at 21:34):
It's like runtime and compile time errors. What if this expression is used in indexing function in database :/
nicola (RIO/SS) (Dec 29 2016 at 21:36):
And it's just a matter of one additional operation to be precise!
Bryn Rhodes (Dec 29 2016 at 21:36):
No, you'd need to support ordering as well, but that's a different issue.
Mario Hyland (Dec 29 2016 at 21:38):
Note: it would be good to capture some of these implementations details (in test cases), and leverage testing to both see what works well, but to ensure folks are (where important) implementing this in a way which supports being interoperable :) - our approach is to avoid exclusive "happy path" testing, we would like to throw some of these examples which would be negative test case. If anyone is able to articulate on this thread a negative (exception) test case, we will evaluate how to test for it - during an FHIR message exchange.
Bryn Rhodes (Dec 29 2016 at 21:39):
And I agree, it's like runtime vs compile-time errors, and some implementations can choose to use compile-time errors, and some can use runtime. FHIRPath allows both. Within FHIR, FHIRPath invariants use runtime because there are lots of cases where the authors know (based on profile information that may or may not be available to the compiler) that a given expression will work, where a strict compiler would force them to use an extra operator.
Bryn Rhodes (Dec 29 2016 at 21:40):
@Mario Hyland There are several negative test cases in the FHIRPath test suite: https://github.com/FHIR/fluentpath/tree/master/tests
nicola (RIO/SS) (Dec 29 2016 at 21:41):
@Grahame Grieve fhirpath also missed min and max functions!
Bryn Rhodes (Dec 29 2016 at 21:43):
Haven't needed them so far.
Bryn Rhodes (Dec 29 2016 at 21:43):
The intent of FHIRPath is to be sufficient.
nicola (RIO/SS) (Dec 29 2016 at 21:44):
The simple place you need it is specify expressions for sorting in search.
nicola (RIO/SS) (Dec 29 2016 at 21:45):
I think all this mess with collection/value is result of xmlish thinking :)
Bryn Rhodes (Dec 29 2016 at 21:46):
Comparison operators can define expressions for sorting in search.
nicola (RIO/SS) (Dec 29 2016 at 21:47):
I mean, you need expression to extract value by which you will sort - to build index
Josh Mandel (Dec 29 2016 at 22:21):
Coming late to this discussion... It seems to me that implicit conversions to/from lists (to satisfy operators that take single input, or to throw an error at runtime if they're unsatisfied) is a "sharp edge" of the language without a huge benefit. But maybe I'm just missing the benefit...
nicola (RIO/SS) (Dec 30 2016 at 13:59):
@Ewout Kramer, @Grahame Grieve why this expressions - <expression invalid="true">name.given1</expression> or <expression invalid="true">Encounter.name.given</expression> are marked as invalid, do you mean we have to verify against fhir structure? This expressions are syntactically valid fhirpath expression, but not valid from fhir resources structure point of view. Should we mix this two things?
nicola (RIO/SS) (Dec 30 2016 at 14:00):
or by invalid you just mean empty result?
nicola (RIO/SS) (Dec 30 2016 at 14:34):
I could not stop :) In fhirpath we have expressions like value.is(Quality) - but in json we have key - valueQuaility in xml - tag valueQuallity - this require backtracking in implementation or usage of FHIR metadata to evaluate such type of expressions - which is not good. And this is consequences of our polymorphics and serialization design. I think, we should serialize into value: {type: 'Quality,...} or <value type="Quality" value=""> or do not use such type of expressions in fhirpath, or at least say it like value[x].is(Quality).
nicola (RIO/SS) (Dec 30 2016 at 15:24):
Do we really need asas operator and as as function?
nicola (RIO/SS) (Dec 30 2016 at 17:56):
https://medium.com/@niquola/query-languages-for-recursive-data-structures-da348036f679#.cc3s55rgt - i've put some thoughts about fhirpath into small post :)
Bryn Rhodes (Dec 30 2016 at 17:58):
Those tests are invalid for is and as, the .is() and .as() functions were removed in favor of the is and as operators.
Bryn Rhodes (Dec 30 2016 at 17:58):
And those were designed as operators so that we can tell in the grammar when we are parsing a type name.
Bryn Rhodes (Dec 30 2016 at 18:00):
And yes, the tests are marked invalid because they are expected to throw an error (either compile-time or run-time). I don't see a problem with having tests that expect a particular data model, though it would be nice if the tests indicated what model they were expected to be evaluated against.
Bryn Rhodes (Dec 30 2016 at 18:00):
The tests are full evaluation tests, not just syntax tests.
Bryn Rhodes (Dec 30 2016 at 18:58):
Here's some background posts that I think address the questions you raise in your blog entry:
Bryn Rhodes (Dec 30 2016 at 18:58):
http://www.healthintersections.com.au/?p=2400
Bryn Rhodes (Dec 30 2016 at 18:58):
https://github.com/cqframework/clinical_quality_language/wiki/FHIRPath:CQL::XPath:XQuery
nicola (RIO/SS) (Dec 30 2016 at 21:17):
@Bryn Rhodes tightly coupling data model and query language is diminish this language applicability/reuse. name.given1 is a worst case of all - compiletime/runtime - because it should take meta data about types in runtime (there is no tips for compile time - it should be at least Patient.name.given1) . You could live with compile time checks, which require a lot of metadata - but it is very difficult to optimize such checks in runtime.
nicola (RIO/SS) (Dec 30 2016 at 21:18):
If you want something like type checking, then annotate it with types, if you are dynamic - then this expression is valid and just return nothing.
nicola (RIO/SS) (Dec 30 2016 at 21:20):
Validation for schema, could be just optional feature on top of schema-agnostic fhirpath (not required).
Bryn Rhodes (Dec 30 2016 at 21:51):
@nicola (RIO) FHIRPath doesn't tightly couple data model and query language. FHIRPath is a generic language that works against any model.
Brian Postlethwaite (Jan 03 2017 at 00:12):
The tests were created to test the implementations that we were creating against the fhir specific extensions to the language also, not just the core language.
The format of the test file as XML isn't important, as its just a source for the test engine, and we needed something to be able to share.
nicola (RIO/SS) (Jan 03 2017 at 08:52):
We have contains function on strings and contains operator on sets and also in example we have ValueSet.expansion.repeat(contains)? Fhirpath is like quest game for implementers, it harms my brain :(
Bryn Rhodes (Jan 03 2017 at 16:56):
The contains in ValueSet.expansion.repeat(contains) is resolved as a property name because it doesn't have parentheses. So the repeat recursively invokes the contains property until there are no more results.
Bryn Rhodes (Jan 03 2017 at 16:59):
As far as similar functions on different types, some of that is inevitable, there are only so many words available, so we tried to go with the most common usages of function names for each domain. Sometimes that results in overlap, not sure how to avoid that.
Grahame Grieve (Jan 03 2017 at 20:48):
@nicola (RIO) can you add a task to add min() and max() functions? Agree thtey are useful for indexing
Grahame Grieve (Jan 03 2017 at 20:49):
you should not confuse the details of the test suite with the language details. We could add test suites for different applications, but a test suite that was application independent would not be very useful, so we didn't define on
Grahame Grieve (Jan 03 2017 at 20:50):
I do intend to do a v2 test suite at some stage
nicola (RIO/SS) (Jan 04 2017 at 10:47):
@Bryn Rhodes for name clashes we could use namespaces: str/contains coll/contains. Bryn, are you sure we need all this temporal algebra in fhirpath, as i understand it was ported from CQL?
Grahame Grieve (Jan 04 2017 at 10:50):
FHIRPath users asked for more than we did
nicola (RIO/SS) (Jan 04 2017 at 10:53):
@Grahame Grieve i've added issue about min/max to gforge. Yes, that's what i'm talking in my blog post - general purpose language at the end!
nicola (RIO/SS) (Jan 04 2017 at 10:58):
@Grahame Grieve have you seen XPath 3 - https://www.w3.org/TR/xpath-30/?
Grahame Grieve (Jan 04 2017 at 11:38):
a little. I prefer not to look :-)
Grahame Grieve (Jan 04 2017 at 11:40):
xml... http://thedailywtf.com/articles/sche-ma ... only look if I really have too... !
nicola (RIO/SS) (Jan 04 2017 at 12:28):
Let do not make fhirpath like this :)
Bryn Rhodes (Jan 04 2017 at 15:39):
@nicola (RIO) FHIRPath doesn't have a temporal algebra, so I'm not sure what you're referring to?
nicola (RIO/SS) (Jan 04 2017 at 21:57):
If we use + to concatenate strings (like in js), should we define -for strings? :) Most of languages do not use + for strings, this is too javascriptish and source of many bugs.
nicola (RIO/SS) (Jan 04 2017 at 22:00):
This differs from + on two strings, which will result in an empty collection when one of the operands is empty.
nicola (RIO/SS) (Jan 04 2017 at 22:03):
This is a joke of the day :) - if we use arithmetic operator on strings and some of strings are empty we return empty collection. Even LISP does not go so far.
Bryn Rhodes (Jan 04 2017 at 22:04):
But every SQL dialect does.
Bryn Rhodes (Jan 04 2017 at 22:05):
If I ask you to concatenate two strings, but you don't know what one of the strings is, what's the right answer?
Bryn Rhodes (Jan 04 2017 at 22:05):
You can choose to ignore the thing that you don't know, but that's making an explicit choice about how to handle missing information, and it's not always the right choice.
Bryn Rhodes (Jan 04 2017 at 22:06):
The more conservative response is to say "I don't know what the resulting string would be because I don't know what one of the inputs is". Which is what all SQL dialects do.
nicola (RIO/SS) (Jan 04 2017 at 22:07):
Please take a look at tons of javascript WTFs produced by such types of implicit conversions , it's a well known bad parts of js
Grahame Grieve (Jan 04 2017 at 22:07):
it sounds like you are talking about different things....
Bryn Rhodes (Jan 04 2017 at 22:08):
We don't define implicit conversions between integers and strings, which is really the source of the gotchas.
nicola (RIO/SS) (Jan 04 2017 at 22:14):
why do not use special operation for strings concatenation? Choice of & for strings also looks strange - it's bitwise operator in c-like languages.
Grahame Grieve (Jan 04 2017 at 22:18):
well, at some point, every special operator is used for something somewhere
nicola (RIO/SS) (Jan 04 2017 at 22:22):
Yes, that's true :) I've just looked into different languages string concat - there are zoo of all possible combinations: Haskell ++, Postgresql ||, Ocaml ^. I forgot in Java it's really +.
Bryn Rhodes (Jan 04 2017 at 22:27):
Yeah, + is I think the most common in traditional languages (C, Java, C#, JavaScript, T-SQL). I also really like & for concatenation, it means "and", so it works conceptually, and hopefully we never have bitwise operators in CQL or FHIRPath :)
Grahame Grieve (Jan 04 2017 at 22:28):
oh yes, don't we all love bitwise operators...
nicola (RIO/SS) (Jan 04 2017 at 22:30):
May be redefine - for strings - for symmetry? It's a joke or may be not. So we'll get algebraic data types.
Bryn Rhodes (Jan 04 2017 at 22:33):
Not opposed to it, but you'd have to define clear semantics. It's interpretable in any number of ways, so it's typically not expressible as a binary operation, needs more input.
Grahame Grieve (Jan 04 2017 at 22:43):
a-b - remove all character sequences b from a - what else could it mean?
Grahame Grieve (Jan 04 2017 at 22:43):
I could see myself using that.... but not often]
Bryn Rhodes (Jan 04 2017 at 22:44):
Remove the first appearance of b, remove the last appearance of b, etc...
Grahame Grieve (Jan 04 2017 at 22:45):
hat's why it could only mean all of them
Bryn Rhodes (Jan 04 2017 at 22:49):
What if removing b resulted in a new appearance of b. Should it keep going?
nicola (RIO/SS) (Jan 04 2017 at 22:53):
LISPER NOTE: empty list as NULL = NIL. We wrap all values in collection - yes functor composability is nice feature, simulating maybe monad by collections - also ok, but i still have doubts about generalising this approach to whole language.
Grahame Grieve (Jan 04 2017 at 22:55):
sure ;-). But I'm not really arguing for this.
nicola (RIO/SS) (Jan 04 2017 at 23:04):
For example - should this fail or return collection of first letters Patient.name.given.substring(0,1) if given.count() > 1? I'm still puzzled with Patient.name.given = 'Nicola' in samples
Grahame Grieve (Jan 04 2017 at 23:06):
the first is clearly documented. the answer is null if it's a collection. So is the second: Returns true if the left collection is equal to the right collection
Bryn Rhodes (Jan 04 2017 at 23:08):
To return a collection of first letters, you'd use select to invoke the substring on each element of the collection.
nicola (RIO/SS) (Jan 04 2017 at 23:21):
@Grahame Grieve But right is not a collection, or we assume it's ['Nicola']. So select is a functional map?!
Grahame Grieve (Jan 04 2017 at 23:22):
everything is a collection. in this case, a collection with a single value
Grahame Grieve (Jan 04 2017 at 23:22):
['Nicola'] = 'Nicola'
Grahame Grieve (Jan 04 2017 at 23:22):
.. you're unique ;-0
nicola (RIO/SS) (Jan 04 2017 at 23:22):
:)
nicola (RIO/SS) (Jan 04 2017 at 23:25):
could we somehow get collection of collections, or they are always flatten?
Grahame Grieve (Jan 04 2017 at 23:26):
don't know.
Bryn Rhodes (Jan 04 2017 at 23:26):
They are flattened in path traversal, but with a select you could get a list of lists.
Bryn Rhodes (Jan 04 2017 at 23:27):
I think. That might need clarification :)
nicola (RIO/SS) (Jan 04 2017 at 23:27):
And my collection constructor is (a | b | c) = [a, b, c]?
Bryn Rhodes (Jan 04 2017 at 23:28):
Yes.
Bryn Rhodes (Jan 04 2017 at 23:28):
Nope, clearly documented, select flattens the results.
nicola (RIO/SS) (Jan 04 2017 at 23:30):
And fhirpath always returns collection as result of expression?
Grahame Grieve (Jan 04 2017 at 23:31):
yes
Bryn Rhodes (Jan 04 2017 at 23:31):
Yes, though for clarity in the documentation, operations and functions that expect singletons are described using the type, rather than the collection type.
nicola (RIO/SS) (Jan 04 2017 at 23:32):
singleton = collection of one element?
Bryn Rhodes (Jan 04 2017 at 23:32):
Yes.
nicola (RIO/SS) (Jan 05 2017 at 09:54):
If everything is a collection, what logical expressions should return - [true], [false]?
nicola (RIO/SS) (Jan 05 2017 at 10:07):
I still argue against expressions like Observation.value.value - which requires fhirpath engine to know about FHIR polymorphics and metadata to evaluate. Please , do not mix this. At least add some hint like Observation.value[x].value. Or as i've already asked, let's encode polymorpics like: {value: {type: SomeType , value: .... or valueSomeType}} - as i see most of ref. libraries use Observation.value getter - that's why you think it's natural to write such expressions, but it's not natural for implementations based purely on data formats (json, xml). It's also simplify json schema :)
nicola (RIO/SS) (Jan 05 2017 at 10:17):
Why in tests comparison of date and time is not type error ? birthDate != @12:00 expected false, not error
nicola (RIO/SS) (Jan 05 2017 at 10:19):
Oh, i see
For dateTime and time comparisons with partial values (e.g. dateTimes specified only to the day, or times specified only to the hour), the comparison returns empty ({ }), not false.
What is motivation not to raise exception?
nicola (RIO/SS) (Jan 05 2017 at 10:21):
And what is difference between {} and false (or [false] :)? - true, false, unknown?
Grahame Grieve (Jan 05 2017 at 11:09):
you can create a task for a future version of FHIRPath to use Observation.value[x] not Observation.value, but I don't like your chances. But you pretty much have to know the same information to resolve value[x] as value, so it doesn't make that much difference.
Grahame Grieve (Jan 05 2017 at 11:09):
the tools ensure, btw, that there'll never be yyyyXXX and yyyy[x] - that would create potential confusion already, so isn't allowed.
Grahame Grieve (Jan 05 2017 at 11:10):
you're also welcome to create a task proposing changing the way polymorphics are serialised, but i can't see it getting up; you're the only one who's bugged by it
Bryn Rhodes (Jan 05 2017 at 15:58):
@nicola (RIO) we added a choice type to CQL 1.2, partly to support FHIR, but partly to support QDM-style unions. FHIR isn't the only data model with choice types, so having a language that can deal with them is a good thing. If you feel strongly about not including them, I'd welcome your comments on the CQL 1.2 ballot.
nicola (RIO/SS) (Jan 05 2017 at 17:44):
@Grahame Grieve i will create tickets. Most of current users just use ref.libraries (which is written by 4 people in the same paradigm of code generation) and do not fill this pain, but think about future users, libraries, databases. Complexity of all implementations are doubled by requirement to keep metadata available for such situations and it's just accidental complexity. Data is self-valuable - why do you want Observation.value in Spec, Java or C#, but do not want it in the same shape in serialised form? This decision forces to write reference libraries (hardcode versions etc), for all engines which deal with FHIR (even partially like fhirpath), without real need. Data format by itself could keep this aspects of model semantic without need for additional tools (like ref libraries). I argue, that this data will outlast all libraries - why it should be freaked?
Last updated: Apr 12 2022 at 19:14 UTC
