Empty objects in API responses

[grantm]

I am trying to integrate the Codepoints.net API with my Unicode Character Finder. A first cut is available here: http://www.mclean.net.nz/ucf/beta/?c=U+0041

Clicking the "U+0041" link in the "Codepoint" field should make an API request for all the properties and display the results in a dialog box.

The main thing I'm having trouble with is that some of the property values are empty objects. For example if I request the "Simple Lower Case" property for U+0041, I'd expect something that referred to U+0061, instead I get:

{"slc":{}}

Am I missing something?

Other things I found a bit odd (but which aren't show-stoppers):

• Some of the properties which I'd expect to be numeric are actually strings. The most obvious example is the 'cp' property for the codepoint number.
• Some of the properties appear to be boolean values but with the string "0" for false and "1" for true, rather than simply being true or false JSON boolean values.
• Some of the 'property' values appear to be non-standard properties added by codepoints.net (e.g.: 'image', 'abstract'). Is there a list of these somewhere? It might be better if the non-standard ones used some prefix on the property name to avoid clashes with future new Unicode properties (I have no idea how likely that is).

Apologies if an issue is not the best place to raise these points.

[Boldewyn]

Thank you for the feedback! You're absolutely right, the empty slc and companions are a bug. I'll look into those.

There was some reasoning re: the numeric values as strings. I'll try to remember, what it was.

For the boolean types, it's what was extracted from the XML representation of the Unicode standard (+ the stringification from above). I agree, converting those to true / false would actually be better.

Non-standard fields: Yes, some way to determine, which info is canonical, should be added. The original idea was to provide (more or less) all data that is also used to render the HTML, but there are use cases (like yours), where knowledge of standard fields is necessary. For the moment, the non-standard fields are image and abstract. (There is a theoretical way to get a whitelist: https://codepoints.net/api/v1/codepoint -> property -> all keys of this list are canonical. However, this is an inconsistency, that should be addressed, too.)

[Boldewyn]

At least the slc use case is fixed now:

https://codepoints.next/api/v1/codepoint/0041?property=slc

For the others I will have to take a look again. There are definitively non-standard fields still in the complete response and no easy way to filter them. The other items I haven’t checked yet.