Stream: conformance
Topic: pattern[x] on 0..* elements
Chris Moesel (Dec 08 2021 at 21:26):
The spec says:
When pattern[x] is used to constrain an array, it means that each element provided in the pattern[x] array must (recursively) match at least one element from the instance array.
That makes sense. I just noticed a behavior of SUSHI that I'm not sure is right though. If I constrain a 0..* element like this:
// inside a Condition profile
* meta.profile = "http://foo.org/StructureDefinition/MyProfile"
It generates an element like this:
{
"id": "Condition.meta.profile",
"path": "Condition.meta.profile",
"patternCanonical": "http://foo.org/StructureDefinition/MyProfile"
}
Notice that although meta.profile is 0..*, the patternCanonical value is not an array. Is that valid? It's never been flagged as an issue, but I'm thinking maybe it needs to be an array, like "patternCanonical": ["http://foo.org/StructureDefinition/MyProfile"].
Lloyd McKenzie (Dec 08 2021 at 22:31):
pattern[x] is, by definition, not a repeating element. The way you have it is fine. The behavior of it on validating is to check the array element and see if at least one element matches.
Chris Moesel (Dec 08 2021 at 22:39):
Doh. You're right. Since pattern[x] is 0..1, then it can't be an array. I think I got tripped up by the phrase "each element in the pattern[x] array" in the spec (see full context above). Since pattern[x] can't be an array, I think that language is a bit misleading and should probably be changed. Would you agree?
Grahame Grieve (Dec 08 2021 at 23:04):
I think that Lloyd is wrong on that, and there's a task to clarify that
Lloyd McKenzie (Dec 09 2021 at 03:33):
What bit am I wrong about?
Grahame Grieve (Dec 09 2021 at 07:08):
it's only inside complex types that one item in the array has to match. if you apply a pattern to a repeating element, all the elements have to meet the criteria. I'm pretty sure we have a FHIR task that clarified that
Chris Moesel (Dec 09 2021 at 13:46):
If that's the case then the spec is pretty misleading on that account. But I guess you'd use slicing if you wanted to call out that just one of the items must match. Still... I wonder how many other people have misunderstood it based on that language.
Chris Moesel (Dec 09 2021 at 13:49):
What about this one?
When pattern[x] is used to constrain a primitive, it means that the value provided in the pattern[x] must match the instance value exactly.
Since primitives allow for id and extension, I always assumed that one reason to use pattern[x] on a primitive (instead of fixed[x]) was to allow for it to still match even if the primitive has an id or extension attached to it. But the description above makes it sound like it wouldn't work that way (and acts exactly the same as fixed[x] for primitives).
Lloyd McKenzie (Dec 09 2021 at 15:55):
Maybe we should have a warning about pattern and fixed values asserted on repeating elements?
Lloyd McKenzie (Dec 09 2021 at 15:56):
Also required or extensible bindings
Grahame Grieve (Dec 09 2021 at 18:52):
we agreed to modify the language to remove confusion
Lloyd McKenzie (Dec 09 2021 at 19:58):
Would a warning not also make sense?
Grahame Grieve (Dec 09 2021 at 20:03):
I'm not exactly sure what you mean by warning
Lloyd McKenzie (Dec 09 2021 at 20:30):
If someone puts a fixed value, a pattern or a required or extensible binding on a repeating element, we'd spit out a warning saying something like "Verify intent is that [x] be enforced on all repetitions of this element". If that is the intent, then the author can just suppress the warning.
Lloyd McKenzie (Dec 09 2021 at 20:30):
But 80% + of the time, it won't have been the intent and they can slice or something to get what they're actually wanting.
Richard Townley-O'Neill (Dec 09 2021 at 23:44):
I think the Jira is FHIR-33316.
It proposes
When pattern[x] is used to constrain an array, it means that each element provided in the pattern[x]
arraymust (recursively) match at least one element from the instance array.
I read that as saying that only 1 member of the array needs to match, not all of them.
Grahame Grieve (Dec 10 2021 at 01:20):
Guess I remember it wrong. @Lloyd McKenzie make a comment on the task
Richard Townley-O'Neill (Dec 10 2021 at 01:58):
I think this was forgotten.
Chris Moesel said:
What about this one?
When pattern[x] is used to constrain a primitive, it means that the value provided in the pattern[x] must match the instance value exactly.
Since primitives allow for
idandextension, I always assumed that one reason to usepattern[x]on a primitive (instead offixed[x]) was to allow for it to still match even if the primitive has an id or extension attached to it. But the description above makes it sound like it wouldn't work that way (and acts exactly the same asfixed[x]for primitives).
Lloyd McKenzie (Dec 10 2021 at 05:56):
I'm pretty sure that pattern on a primitive still allows for id and extensions - that was indeed the whole point.
Lloyd McKenzie (Dec 10 2021 at 05:58):
What comment do you want me to make @Grahame Grieve?
Grahame Grieve (Dec 10 2021 at 08:30):
note about making a hint from the validator
Lloyd McKenzie (Dec 10 2021 at 14:11):
The note might not be needed if a pattern only impacts one repetition. (Though I might want to submit a new tracker around fixed values and fixed & extensible bindings.)
Chris Moesel (Dec 10 2021 at 14:20):
OK. Now I'm confused. So we're back to saying that pattern[x] on a 0..* element only needs to match one element (not all elements)? If this is true, then the common approach to fixing an Observation.category in a profile using slicing does not actually have to use slicing?
image.png
Chris Moesel (Dec 10 2021 at 14:20):
The above could have just used the pattern[x] directly (without the slice)?
Grahame Grieve (Dec 10 2021 at 19:50):
that's why we need a note either way, @Lloyd McKenzie. I'm really surprised because I did think that we decided applying a pattern to a repeating element applied to all of them (at the root). And because deciding something else has known on consequences
Lloyd McKenzie (Dec 11 2021 at 05:20):
Do you want us to re-open?
Richard Townley-O'Neill (Dec 13 2021 at 01:49):
Grahame Grieve said:
... I'm really surprised because I did think that we decided applying a pattern to a repeating element applied to all of them (at the root). ...
That makes more sense to me.
Eric Haas (Dec 14 2021 at 06:37):
I don't see how FHIR-33316 can co-exist with this normative part of the spec.
If a required[/extensible] binding is applied to an element with maximum cardinality > 1, the binding applies to all the elements.
I will state I'd prefer if to be the other way ( at least one) but the die has been cast here.
Eric Haas (Dec 14 2021 at 06:49):
This prompted us in US Core to clarify when a slice with a binding is really an extensible binding.
Lloyd McKenzie (Dec 14 2021 at 16:09):
You can have a slice with an extensible binding, but not if you're slicing by that binding.
Grahame Grieve (Dec 22 2021 at 07:09):
I do think we should re-open this, yes. There's obviously confusion here for sure
Lloyd McKenzie (Dec 22 2021 at 15:14):
@Yunwei Wang - can we add this to the agenda for our next call?
Chris Moesel (Apr 01 2022 at 19:57):
This has come up again and I don't see any further clarification on FHIR-33316. Was this discussed and decided upon? If so, which is it:
- A
pattern[x]on a repeating element must match every element in the instance array, OR - A
pattern[x]on a repeating element must match at least one element in the instance array?
John Moehrke (Apr 01 2022 at 19:58):
How could "must match every element" be useful at all?
John Moehrke (Apr 01 2022 at 19:58):
And, the IG publisher decorates these today with "at least..."
Gino Canessa (Apr 01 2022 at 20:25):
Trying to sync from the sushi thread, so forgive my :train: of :thought: (and, happy Friday =).
Currently, I am working through ElementDefinition.pattern[x] in the context of ElementDefinition.fixed[x], which is conceptually simpler and I think should be applied the same way (they are siblings with near identical definitions/purposes).
If you defined an element that was 0..* with a fixed value-string of why?, I think the expectation is that every element of that array would be a value string of why?. It does not feel particularly useful to do so, but I also cannot think of how else the definition makes sense.
Following that through, if you define a pattern for an array, I would assume that all elements in the array must follow the pattern (e.g., fixing a system but allowing for multiple codes from that system).
If the desire is for a single value in an array to follow the rule (either a fixed value or a pattern), then it needs slicing.
Thoughts?
Chris Moesel (Apr 01 2022 at 21:12):
I'm not sure I agree with the approach of trying to make fixed[x] and pattern[x] work consistently for this. The primary difference between pattern[x] and fixed[x] is that the whole idea of pattern[x] is to define minimal criteria for matching, while allowing for additional values. IMO, I think it would be confusing to have pattern[x] work one way on the top-level array ("all must match") and another way on nested arrays ("at least one must match").
If we agree that wanting to set a pattern on every instance of an array is the minority use case, then perhaps it is the use case that should require slicing (create a closed slicing discriminating on $this, with a single slice, applying the desired pattern on that slice).
Chris Moesel (Apr 01 2022 at 21:18):
That said, I totally understand @Eric Haas's concern (above) about the inconsistent behavior between pattern[x] and required bindings on repeating elements. But... I'm not sure the FHIR spec ever explicitly says that bindings use pattern semantics. There is an "at least one" behavior when applying a binding to a CodeableConcept, but that is on the coding, not the CodeableConcept itself.
Chris Moesel (Apr 01 2022 at 21:19):
BUT... if the decision was already made back in December, and just not documented here, I'm glad to take whatever verdict was reached!
Gino Canessa (Apr 01 2022 at 21:59):
I don't think any decision was made on this - the ticket I saw was about correcting an extra-word typo in the comments.
I can see that we are difference from different angles. I am thinking of it for things like 'require this system, but allow any code', and I believe you are thinking 'one of the elements must behave this way'.
I want to make sure I have a few things right in my head. Based on the definition of pattern, I believe these two are not-contentious:
- If the pattern is on a scalar primitive element, it behaves the same as fixed (e.g., pattern of 1 string is essentially a fixed value).
- If the pattern is on a scalar complex element, it behaves as 'must have this element:value pair' (e.g., a fixed system on a coding)
Assuming that is the case, we need to expand into arrays. I believe you are advocating for:
- A pattern on an array-primitive means that one of the elements has the value.
- A pattern on an array-complex means that one of the elements 'must have this element:value pair'.
While my understanding of pattern is (not sure if this is what I want it to be or not, just what I read the current definition to mean =):
- A pattern on an array-primitive means that all elements have the value (same as
fixed) - A pattern on an array-complex means that all elements 'must have this element:value pair` (e.g., all codings are from the same system)
Getting to the end of the day here, so the rest of my thoughts are less organized than I would like...:
-
Since
patternis on the root of an element, I think it should be applied across all of it. If you want something to apply to a portion of the definition, slicing is the mechanism we have for that.
** I think the hesitation around slicing is caused by complexity (I know some exists for me).. if we need more documentation/tooling/etc., that should be addressed - and yes, I know I am preaching to the SUSHI choir here =). -
Since slicing already does this, it anyone using this 'type' of thing needs to be careful with both (e.g., the snapshot/differential viewers probably need to create that 'implicit' slice, because I am not sure how to read something that has both).
- Conversely, if we want to define an element like
oneOfor some such, that is clear to me (though if we are adding that, I would suggest it be 0..*, so that you can express things like either SNOMED or LOINC).
Lloyd McKenzie (Apr 01 2022 at 22:12):
The trick with pattern is that it's defacto "must look like this" as opposed to "must be this". We certainly know that if you have a patternCodeableConcept with a single coding defined in it that the expectation is that 'one of' the Codings within the instance needs to match, not all of them. On the other hand, if you had a fixedCodeableConcept with a single coding, that would mean the instance needed to have exactly one coding.
So it's not a stretch to say that the behavior for repetitions that is true for children is true at the top level too. I'm not arguing that we must say that, just that there are grounds for treating things differently.
Note: pattern on a scalar primitive does NOT behave the same as 'fixed' - you can always have 'id' or 'extension' elements that aren't part of the pattern, while with 'fixed', you can't.
Chris Moesel (Apr 01 2022 at 22:16):
I had typed out a whole long response saying basically the same things that Lloyd just said. But I'm glad you beat me to it, @Lloyd McKenzie -- because you said it much more clearly and succinctly than I was saying it! :-)
Gino Canessa (Apr 01 2022 at 22:26):
Nice, thanks! So the discussion is that if you have a patternCodeableConcept on an array: is the requirement that one of the top-level elements meets the pattern or that all of the top-level elements meet the pattern?
John Moehrke (Apr 01 2022 at 22:30):
Im glad you asked... because I didn't understand where this was going.
John Moehrke (Apr 01 2022 at 22:33):
I still can't quite figure out what the usefulness of having the meaning of patternCodeableConcept on an array meaning ALL. I just don't understand what use-case this is addressing.. THUS, I prefer this be "at least..." interpretation
Gino Canessa (Apr 01 2022 at 23:02):
Conversely, I am struggling to see why you would define a pattern that doesn't apply to all elements in the top-level array - if you want to describe one element of the array, that is literally a slice =).
John Moehrke (Apr 01 2022 at 23:29):
well, my use-case is that in a profile I want to demand that 'at-least' one code in a codeableConcept element be the code X. I have many of these. There are many of them in the IPS specification(where they have been forced to use slicing to get the at-least behavior). I know I can do it with slicing if I must.
I think the IG publisher is indicating that what I am doing is "at-least" meaning, so it is frustrating that it is not acting like that.
John Moehrke (Apr 01 2022 at 23:30):
I don't quite understand what use-case calls for mandating that all instances of a CodeableConcept be code X; if that is the need, then just set it to 1..1 and code X. What use is it to force all repetitions be code X?
Gino Canessa (Apr 01 2022 at 23:37):
I see the pattern as the other way around - e.g., if you are profiling to say that every element of the array must have at least one value from the LOINC system. Every element follows the pattern of having one concept from that system.
Gino Canessa (Apr 01 2022 at 23:39):
And if I am reading your issue correctly John, you are saying that you know how to do what you want with slicing, but do not want to use slicing. If that's correct, we should figure out what else we can do to make slicing more palatable.
John Moehrke (Apr 02 2022 at 14:32):
well, I just now learned that many profiles I have written will not work as I expected they will work. An expectation that was reinforced by the IG publisher telling me that was how it was going to work... Now I learn that the IG publisher has been lying to me... so alot of profiles now need to be changed to this clunky slicing method. So, I don't think this is just me wanting to be lazy.. I think this is more about me exposing what are likely many other profile author expectations
Eric Haas (Apr 02 2022 at 14:40):
I had to rewrite many US Core profile too for the same reason - so now ugly slicing all over the place.
figure out what else we can do to make slicing more palatable.
That would be the at least one behavior for coded elements just like with bindings on the datatype. The binding acts just like a pattern. it says at least one of these has to be X. Can we do the same for elements? e.g., for repeatng element Y at least one is LOINC and call it pattern binding?
Alexander Zautke (Apr 02 2022 at 16:18):
I don’t follow why it would be necessary to re-write a profile? Which other tooling except SUSHI interprets a pattern[x] not as a “at least one” match? We discussed this topic already for the .NET tooling internally at Firely. The main issue would be that you could not enforce the same rules across all FHIR versions.
Alexander Zautke (Apr 02 2022 at 16:24):
Additionally, the last change to ElementDefintion and Slicing, were the adjustments for type slicing in R4. That was incredibly painful. Not sure if the change would be worth it just in order to harmonize it.
Patrick Werner (Apr 02 2022 at 17:32):
I am also confused here. Always thought pattern[x] means at least one match on an array. Can‘t verify at the moment; but doesnt the .net and java validator are also validating this as „at least one match“?
Richard Townley-O'Neill (Apr 04 2022 at 03:55):
I have read element.pattern[x] as applying to every instance of a repeating element, just as element.type applies to every instance of a repeating element.
Richard Townley-O'Neill (Apr 04 2022 at 03:55):
Not so useful, but quite consistent.
Grahame Grieve (Apr 04 2022 at 11:43):
I'm sure we clarified this language somewhere
Grahame Grieve (Apr 04 2022 at 11:44):
in the task. I don't see how the agreed resolution doesn't resolve this question
Chris Moesel (Apr 04 2022 at 13:24):
@Grahame Grieve -- that task was last updated in Nov 2021. BUT then, on December 10 (in this thread) you said this:
I'm really surprised because I did think that we decided applying a pattern to a repeating element applied to all of them (at the root).
(Which is the opposite of what the task resolution says).
And on December 22, you said the task should be re-opened because there was obviously a lot of confusion regarding it. But then, after that, it was never mentioned again.
So, given that you said you disagreed with that outcome and called for it to be re-opened, I wasn't sure I should trust that the task resolution is stable. If you're saying the resolution will stand as-is (the pattern must match at least one in the array), then great. We'll go forward with that. Is that what you're saying?
Grahame Grieve (Apr 04 2022 at 13:24):
I was surprised, but I think I became resigned to it. Or something
Grahame Grieve (Apr 04 2022 at 13:25):
I don't remember whether it was dsicussed or not
Gino Canessa (Apr 04 2022 at 16:17):
Maybe thinking of FHIR-18296 for other discussion? The only other ticket I have seen referenced in this thread is FHIR-33316 , and as seconder I can pretty confidently say there was no discussion beyond the request in the ticket (remove the additional word from the text).
If everyone has been using pattern as 'one from the array', :shrug: - we can clarify it and move on. But it still does not feel correct to me - to jump back to an earlier example from Lloyd:
Note: pattern on a scalar primitive does NOT behave the same as 'fixed' - you can always have 'id' or 'extension' elements that aren't part of the pattern, while with 'fixed', you can't.
So if I have a pattern on a scalar primitive saying it requires an id, great! I can assume any valid content will have an id. My understanding was that if a resource now has two of those elements, they should both have an id. If the argument is that only one of those values actually needs an id.. that feels a bit odd. For example, you can no longer use the pattern to validate individual elements, since they rule may or may not apply. Yes, that is true for slicing, but it is explicit about it - e.g., ordered vs. unordered, how to find the match, etc.
For a more concrete example, I am thinking of a pattern that requires names to have a prefix - I would expect every name to have to follow that pattern, instead of just one value out of the array. If you want to say that a name must have a prefix, I always thought that was the realm of slicing.
Chris Moesel (Apr 04 2022 at 18:01):
Hi @Gino Canessa -- I understand what you're getting at, but I'm not sure your example is fully correct:
So if I have a pattern on a scalar primitive saying it requires an id, great! I can assume any valid content will have an id.
You can't use pattern[x] to assert that something should exist. You use pattern[x] to assert specific values. For pure existence, you would just change the id's min cardinality to 1. So this does not really apply to the pattern[x] discussion.
But let's say that you wanted to say that Patient.address should only allow use: billing. So even if there are multiple addresses, every one should have "use": "billing". You could try defining a patternAddress on Patient.address with { "use": "billing" }. But then that would mean that only one address needs to fit that pattern (based on the "at-least-one" interpretation) -- and I think that's the point you're trying to make. But I think that might be OK -- because you can just set a patternCode on Patient.address.use instead -- and that would give you exactly what you want. So there is still an approach that works (without needing to slice in either case).
Eric Haas (Apr 04 2022 at 18:40):
Here is a concrete example:
from US Core 3.1.1 Condition:
Eric Haas (Apr 04 2022 at 18:43):
so now in US Core 4.1.0 Condition:
Eric Haas (Apr 04 2022 at 18:45):
if we flip flop on the interpretation of pattern. will remove the slice and apply pattern on the element.
Rob Hausam (Apr 04 2022 at 18:57):
The 4.1.0 Condition example is exactly what I would expect. I think we would not want to change the behavior of the value set binding at the element level on a repeating element. When the data type is CodeableConcept, as in this case (and probably all or at least nearly all similar cases), then you still have the multiple codings available in each instance of the repeating element where you can send all of the other appropriate "translation" codes (regardless of whether or not they are in the bound value set).
Gino Canessa (Apr 04 2022 at 19:14):
Thanks @Chris Moesel - a bit too far down the simplification-train =). That said, I feel like your example illustrates the same point.
I am of the opinion that those two ways of asking for use of billing should be equivalent, since you are defining a pattern for the content of that element. If you want to describe a single element of an array, it should be done via slicing.
Conversely, if we are describing 'one element of the array should look like this', we should have an element on ElementDefinition that is 0..* instead of 0..1, where you can list all of those things. E.g., I want a billing and a home. This is (to me) equivalent to slicing.
(edit: wanted to explicitly note that I am not willing to die on this hill, because reading my comments it may sound like I am... need to figure out how to soften that in typed content =)
Chris Moesel (Apr 04 2022 at 19:25):
@Gino Canessa - Agreed. At this point it seems a matter of either perspective or preference. I don't think there is a "right" answer and I'm not willing to die on this hill either. I just want to know the final answer so I can make sure that SUSHI works correctly. ;-)
Gino Canessa (Apr 04 2022 at 20:35):
@Chris Moesel , since I didn't see you on FHIR-I today: FHIR-36700 resolves this (though not applied yet). Someone can jump in if I miss something, but generally* the idea is that pattern[x] applies to everything, if you want to describe things in one element of an array, use slicing.
*I say generally because there is still the fun behavior of elements that contain their own arrays - e.g., when drilling down into a CodeableConcept, only one of the members of that array needs to meet the pattern.
(edit: details notes on the ticket)
Patrick Werner (Apr 04 2022 at 20:43):
(deleted)
Chris Moesel (Apr 04 2022 at 20:46):
Thanks @Gino Canessa! I didn't realize that this would be discussed (although I probably should have guessed it) -- but I had a conflict anyway. I don't have permissions to edit FHIR-33316, but would recommend that someone at least comment on it to point toward FHIR-36700.
John Moehrke (Apr 04 2022 at 20:50):
wonder if the IG publisher should throw a warning when someone tries to use pattern[x] on an array, to prevent someone from thinking it does something it doesn't do? Those that really mean it, can put in a ignore warning. (I am thinking that I am going to be hard pressed to find all of these places where I made that mistake)
Grahame Grieve (Apr 04 2022 at 20:51):
@Patrick Werner
Patrick Werner: To be honest, im very concerned about this change, which breaks the current validators. I had prefer to clarify the wording to reflect established reality by implementers.
I don't think it's a change to current validators. Certainly not the java one. I reviewed it while we drafted the changes
Patrick Werner (Apr 04 2022 at 20:53):
Grahame Grieve said:
Patrick Werner
Patrick Werner: To be honest, im very concerned about this change, which breaks the current validators. I had prefer to clarify the wording to reflect established reality by implementers.
I don't think it's a change to current validators. Certainly not the java one. I reviewed it while we drafted the changes
oh! Then i mixed sth up. Never mind. Having a consistent behaviour across all implementations is a good thing.
Patrick Werner (Apr 04 2022 at 20:54):
John Moehrke said:
wonder if the IG publisher should throw a warning when someone tries to use pattern[x] on an array, to prevent someone from thinking it does something it doesn't do? Those that really mean it, can put in a ignore warning. (I am thinking that I am going to be hard pressed to find all of these places where I made that mistake)
would appreciate that as well. Used to profile like this in the past (at least i think, have to search for these profiles).
Patrick Werner (Apr 04 2022 at 20:55):
Thought that this was an elegant solution for the min 1 rep should look like this problem. But i was wrong. Slicing it is.
John Moehrke (Apr 04 2022 at 20:56):
I just know that I have many profiles that I must now look thru for if the assignment in the profile is against a ..1 element, for which I will not change it... or against a ..* element, for which I now need to replace with slicing.
John Moehrke (Apr 04 2022 at 20:57):
so, i proposed some decoration in sushi for this... where as here I just proposed an IG publisher warning (info?)
Patrick Werner (Apr 04 2022 at 20:57):
Gino Canessa said:
*I say generally because there is still the fun behavior of elements that contain their own arrays - e.g., when drilling down into a CodeableConcept, only one of the members of that array needs to meet the pattern.
(edit: details notes on the ticket)
So the wording should reflect that a pattern on a nested array means at least one nested element repetition has to comply with the pattern on that array. Right?
Patrick Werner (Apr 04 2022 at 21:00):
John Moehrke said:
so, i proposed some decoration in sushi for this... where as here I just proposed an IG publisher warning (info?)
I think a warning/info? would be good, in the IG Publisher and in Simplfiers QA check. Especially people working with .net are had the option to us pattern wrong.
Gino Canessa (Apr 04 2022 at 21:15):
Patrick Werner said:
So the wording should reflect that a pattern on a nested array means at least one nested element repetition has to comply with the pattern on that array. Right?
Yes, that is the goal of the 'recursive' line - and part of why we also asked for examples for all of the cases. It is tricky to wordsmith by committee - but I believe the intentions are clear now (e.g., every element of the array must have something that meets the pattern - if the pattern is in a sub-array, then only one element of the sub-array needs to match).
E.g., a pattern specifies that every element must have a LOINC code, but that pattern does not prevent an element from also having an equivalent code from another system.
Grahame Grieve (Apr 04 2022 at 21:18):
@Patrick Werner can you clarify this?
Especially people working with .net are had the option to us pattern wrong.
the option to use it wrong?
Grahame Grieve (Apr 04 2022 at 21:29):
next release will make a hint on profiles about this
Alexander Zautke (Apr 04 2022 at 21:34):
Sorry about my earlier comments about the validators. Should have tested it more throughly! It’s a breaking chance for the .NET implementation if you have a pattern on repeating elements with a primitive type.
Alexander Zautke (Apr 04 2022 at 21:35):
For complex types it matches the behavior of the Java one.
Grahame Grieve (Apr 04 2022 at 21:39):
ouch
Last updated: Apr 12 2022 at 19:14 UTC
