Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ


I’ve a canonical type defined as follows:

type CanonicalXYZ mixes Canonical<CanonicalXYZ> {
  @ser(name="Building ID")
  buildingId: string
  . . .

Now I’m using ser annotation to map what’s been uploading in the CSV to the right field, Here is an example of the CSV data I am expected:

TagName,Building ID,Units,Energy,Description,Measurement

The problem is when I upload data, it fails with this error:

 Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ Invalid value path 'Building<*> ID' at 9 for type CanonicalXYZ
 at ...

Is there another option to map the field name in the CSV to its name in the canonical file?


Hi Bachir,
Spaces are not accepted in field names at the moment.


The fields in a type become variables or attributes in an object. Variables can not be defined with spaces in many programming languages. The fields in a persistable type also become a column names in the database. Many database systems don’t allow spaces in the column name. Therefore, spaces in the field will most likely never supported.


You guys are missing the point, there is no type with a field such as ‘Building ID’, instead this annotation @ser indicates that when SERIALIZING a type to csv/xml, to use ‘Building ID’ in that text representation of an instance of a type.

I think this is either a missing feature or a bug.


thanks @rileysiebel, I remember seeing in the documentation that @ser is for serialization, which could be confirmed with

> CanonicalXYZ.csvHeader()

I thought it could also works for de-serialization.


@bachr i think it SHOULD work the way you want it to. There should be a way to do what you’re trying to do, i’m just not sure what that way is.


The spaces in column names should be escaped, either before the import or during the import.
EDIT: My previous quote was ambiguous.

By escaping I mean any function from alphabet X to alphabet Y where Y is not a superset of X, i.e., Y does not contain (i.e., cannot handle safely) some characters of X. You pick one character u from Y and call it the escape character, and the remainder is called Z. Each character c in X that is not in Z, as well as character u itself if it is also in X (i.e., c is in X\Z), becomes escaped as uc' where c' is in Z', a subset of Y of the same size as X\Z, and mapping u: Z' -> X\Z is bijective (I use u for both the escape character and the unescape function), so there is the inverse escaping function, e: X\Z -> Z' (sorry for the unintuitive naming).

This is a systematic way to tunnel problematic characters through “an unsafe environment”. However, it is rarely used properly, and that is why spaces and similar characters should be avoided.


Space doesn’t work in all scenarios. Please avoid using space in any field name otherwise you are begging for trouble down the road.


I agree that it should be avoided. Regardless, it can be handled when importing CSV into C3, if there are no other possibilities.