Update 33128/r18/urn_3GPP_ns_li_3GPPXLAExtensions.xsd

Don't think this is correct (or at least it is is redundant)? LocationOutcomes already permits an undounded number of instances of the LocationOutcome alternation.

A single outcome may have both an error and a location (if RAN Paging fails, the RAN returns the last known location to the AMF. We would still want this returned, but also an error stating that the paging failed)

Sure - so in the original formulation that would be:

<LocationOutcomes>
  <LocationOutcome>
    <Location>{blah}</Location>
  </LocationOutcome>
  <LocationOutcome>
    <FailureCause>{blah}</FailureCause>
  <LocationOutcome>
</LocationOutcomes>

Your way is also valid, but not a pattern we've used to date. And I don't think we need both.

Mark

wouldn't the case when the RAN returns the last known location already be included in the currentLoc attribute be set to false in the ProvideLoc Response and therefore in the locationOutcome?

the issue with using the original formulation that way, it does not tie a the failure to the last known location. in my mind, for each ProvideLocInfo operation there should be a single LocationOutcome with either a location, a failure, or both. In most cases, we should get a single location outcome per LI_HILA request, but if the UE is registered over multiple access types, then we could theoretically get multiple locations returned.

@turkovic yes, but there should also be a failure cause explaining why the current location was not included and we would like that reported as well

Ah, OK - I hadn't appreciated that you want to have some kind of correlation between multiple pairs of location + failure. But the alternative formulation allows an infinite number of inner elements within each, which is also not ideal.

If the pairwise correlation is the most important thing, then the closest pattern we have already used would be to change the choice to a sequence and make both elements optional (with the prose insisting that at least one is populated).

I don't think that it could include an unlimited number of them. I could be wrong, but I think by default, choice only allows 1 of each element. To allow multiples of an element, they would have to also have a maxOccurs. Just to be explicit, I added maxOccurs=1 to each.

If you don't like that idea, I will settle for putting it in the prose and changing it to a sequence.

I don't believe that's how the maxOccurs facet in a choice works - it will simply validate an unlimited number of elements as long as each choice element is valid. Each choice element has a default maxOccurs of 1 anyway - so an infinite list of them will validate as an infinite number of repetitions (allowed by the choice maxOccurs=unbounded) of single instances of each choice element (from the maxOccurs=1 on each choice element which is there regardless of whether you specify it or not).