Is EFB PLN ICAORegion only required for 'User' waypoints a SDK docs error?

Re EFB Flight Plan XML (PLN File) Properties

The docs for the EFB PLN file format don’t include a complete example of a lat/long ‘User’ ATCWaypoint (all gliding waypoints are those) but also suggests that PLN file entry would require an ICAORegion value:

Is that a docs error and the requirement is the other way around i.e. for non-User waypoints?. The “User” Waypoints only use a custom name and a WorldPosition.

Also (not wishing to combine multiple points in one post) could the contents requirements for some strings in that EFB PLN format be more specific?

E.g. <title> should generally follow the format of “[departure_airport ] to [arrival_airport ]” - why? What difference does that make to the sim? Pretty much all gliding flights launch/land at the home airport so essentially that would make the title the same for every flight. How long can the string be?

<Descr> is used to give a short description of the flight plan” - how short does it have to be? My suggestion here is don’t set a small limit just because the current webapp code needs that - if it needs to truncate the string for application reasons then add ellipsis when it’s displayed. Or fine, set a short max limit in the file because the webapp has to have that, but at least specify it.

Yes, that sentence in the docs appears to be reversed. The element is required when the waypoint type is not User.

The convention of the content in the Title element has no effect on the sim whatsoever. This is merely a convention suggestion.

There has been no change in the parsing of either the Title element nor the Descr element for the 2024 EFB spec. They go through the same code in the 2020 PLN version as the 2024 EFB PLN version. These elements already exist and were not added specially for the EFB in any way. Whatever sim internal parsing limitation were there in 2020 would remain in 2024 (which is to say I don’t think there are any other than the internal max string allocation length of the whole XML parser system in general, which I think is something like 2048 or 4096 chars).

Thanks,
Matt