combo box content in metadata editor is not alphabetical

[paregorios]

For example, in the DCLP metadata editor when editing bibliographic entries, there is a long list of possible values for the reference system. If these were to appear in alphabetical order, it would be easier to find and pick the one the user is looking for:

[paregorios]

@rla2118 please prioritize

cc @rogerbagnall, who reported this issue

[ryanfb]

It's difficult to tell where exactly these values are coming from. It seems to be here https://github.com/DCLP/sosol/blob/master/public/javascripts/dclp.js#L121-L184 or here https://github.com/DCLP/sosol/blob/master/public/javascripts/dclp.js#L325-L346

But those are missing several values that are visible in the screenshot attached to this ticket, such as "Line" or "Chapter". Also there appear to be several repeated values, both in the screenshot and in the JS. Somewhat disconcertingly some of these map the same user-visible string to different form values, such as:

<option value="pp">Pages</option>
<option value="pages">Pages</option>

[Edelweiss]

https://github.com/DCLP/sosol/commit/4b10085a9540138b7ec0cd33646cc94216506bd8

[jcowey]

I have made a spreadsheet of the values used in column A and of the list that we would like to change to (in other words getting rid of the duplicates, noted by Ryan above) in column B:

https://docs.google.com/spreadsheets/d/1bnd9Mtuooj1PB8qwNGRphBnkUwB0QZxyLIDYmcbS3C4/edit#gid=0

Would you, @paregorios , please assess what knock on effects / requirements that would have for XSLT. Obviously Carmen would have to make many change and replace commits to DCLP files which contain XML encoding that we would be changing.

[jcowey]

There is an issue from nearly two years ago, in which the @unit / @type on biblScope was flagged: https://github.com/papyri/idp.data/issues/9.

Carmen and I did go through the data in HGV and Biblio, but never got everything together in order to push for an upgrade of the XML in papyri.info. This is still something we would like to attend to sooner rather than later.

[paregorios]

While resolving #325, I also laid in flexibility for dealing with the various possible values of biblScope@type and biblScope@unit across the collections, so @jcowey and @Edelweiss I believe that you are clear to go ahead and make the data and code changes discussed above.

If you want to see all the values for which we now cater, have a look at https://github.com/DCLP/navigator/blob/master/pn-xslt/htm-teibibl.xsl#L14

All the bibliographic formatting code now checks for any of the relevant values in either @type or @unit, thereby making output as uniform as possible across DCLP, HGV, DDB, and Biblio even though there are differences in underlying encoding.

[Edelweiss]

as of now

• book
• chapter
• col
• columns
• fasc
• fascicle
• folio
• fragment
• fragments
• generic
• inventory
• issue
• line
• lines
• no
• number
• numbers
• page
• pages
• pp
• parts
• plate
• poem
• side
• tome
• vol
• volume

[Edelweiss]

as desired

• book
• chapter
• column
• fascicle
• folio
• fragment
• generic
• inventory
• issue
• line
• number
• page
• part
• plate
• poem
• side
• tome
• volume

[Edelweiss]

deprecated

• col
• columns
• fasc
• fragments
• lines
• no
• numbers
• pages
• pp
• parts
• vol

[Edelweiss]

https://github.com/DCLP/idp.data/commit/531efd190e50f4de45773d275fb5a011baffdc16 https://github.com/DCLP/sosol/commit/f56cccbc6c95169eb2645cf32138f721f8d6d08c

[Edelweiss]

https://github.com/DCLP/sosol/commit/0707a0a51f90fa65b1ad9a912552ff86e705cef7

[jcowey]

This has now been tested and functions well. There is a warning not which tells the user / editor what the chosen value was and invites the user / editor to choose the appropriate one from the drop down menu. Once the correct value has been chosen the warning disappears.