do not allow "/" in 'name' fields of schema

[bendichter]

No description provided.

[CodyCBakerPhD]

@bendichter @luiztauffer Old issue, I know, but this is actually going to be hard to enforce in the json schema when it is acting on paths. They have to be converted to strings even if they are really intended to be Path objects since json doesn't make the distinction.

We can definitely do it for any strings that we hard-code for some reason within the ecosystem, however.

[luiztauffer]

we might have regex rules for string fields of pynwb classes schemas, we would have to adapt our get_schema_from... functions to include that. We would probably like to exclude any special characters from name fields for example.
But yes, it is not possible to exclude / for source_data and conversion_options, which contain paths as strings.

[CodyCBakerPhD]

@bendichter Can this be closed?

[bendichter]

I don't think this has been fixed, has it?

[CodyCBakerPhD]

Can you point to a specific place or set of places where it still needs to be fixed? Or was this an assertion type thing to apply to user specified metadata values that aren't path-like?

[bendichter]

I was thinking we could use regex in the json schema to ensure that the "name" field of objects does not include a slash. If it does, this might be taken as an instruction to create a sub-group.

[CodyCBakerPhD]

Aha, I see. Just applied to name or any other fields you can think of?

[bendichter]

Well any field that would become the name of an HDF5 Group, but I think "name" is the only one that applies to