Stream: terminology
Topic: Expansions
Grahame Grieve (Dec 08 2017 at 05:56):
While we're talking about expansions, any opinions about GF#13232? : Details (Edit)
On the value set pages the display of code expansions on listing up to a 1000 codes is not useful. Who realistically is going to browse >20 items? I recommend truncated the valiues to a human readable 20 or so codes. The full list of codes can be accessed barring IP issues elsewhere in the spec (note: there is no "elsewhere")
Yunwei Wang (Dec 08 2017 at 14:53):
Agree on the > 1000 parts. Maybe limit the list to 50. We can provide an example query for how to get the full/partial list from terminology server.
Simone Heckmann (Dec 08 2017 at 18:36):
How about rendering only the first 20 on the html page but have a full(er) expansion in the xml/json representations in case someone cares...?
Simone Heckmann (Dec 08 2017 at 18:37):
...which technically I guess would mean to stop the narrative generation after the 20th code...
Eric Haas (Dec 08 2017 at 18:39):
I was thinkng along the lines of @Yunwei Wang
Rob Hausam (Dec 08 2017 at 18:41):
20 codes is probably enough to get a sense of the content in most cases, but just barely. 50, along with an example query, as Yunwei suggests, seems pretty reasonable to me, too.
Brian Postlethwaite (Dec 08 2017 at 21:43):
The code generators are using these expansion to generate enumerations in some cases, so would be nice not to have to update that code if can be avoided.
the enumeration of resource types for example.
Brian Postlethwaite (Dec 08 2017 at 21:44):
(specifcally where the binding is required, and of type code - but do have other cases too)
Grahame Grieve (Dec 08 2017 at 21:53):
well, none of those expansions have the size problem
Brian Postlethwaite (Dec 08 2017 at 23:36):
(Just making sure in case it got broadened in scope)
Last updated: Apr 12 2022 at 19:14 UTC
