Question about allowable FieldDictionary keys

We can see by looking at a 3dm, how a RenderContent’s FieldDictionary is persisted in xml, but I have found nothing in documentation indicating limitations on allowable keys. The question arises due to the choice of using keys as the xml element names, with type being put in an attribute, rather than the other way around, which would avoid this problem.

Testing, it appears that with the exception of spaces (which work in the dictionary at runtime, but fail file IO), whatever xml parser is used is able to tolerate at least some illegal element names.

So I am asking for clarification on what is supported, because I have need to use keys which work, but which are technically illegal xml element names, and have not yet come up with any escaping scheme for the keys in question, which would not also generate illegal names.

I believe the XML parser in use for RenderContent is the work of @andy and @johnc. I think it is a custom implementation.

I guess it is up to the (custom) render content developer to ensure valid names, although I can appreciate the fact that this part isn’t documented.

I think the unspoken convention is to use keys that are all of the form [a-zAZ][-a-zA-Z]+, but indeed it would be good to have this explicitly documented somewhere. At least FieldDictionary Class is missing this information.

I suppose for now ensure you use valid XML tag forms.

I have logged two issues to ensure we don’t forget.

RH-64872 Document valid names for FieldDictionary

RH-64873 Don’t allow invalid names

I don’t think you can go so far as disallowing illegal names, since that would potentially break the existing render content of anyone who has used FieldDictionary as though it was a dictionary, without thinking much about how it is internally persisted. I think there are only three options:

  1. document exactly how the implementation is limited, and keep behavior unchanged.
  2. swap the storage of key and type in the xml, to remove the limitation.
  3. switch to a different internal format, to remove the limitation.

There exists another reason to choose one of these options: as a plugin writer, I want my own clients to be able to interoperate with my render content via scripts/plugins/etc, and I want it to be natural for them, not involving either confusing escaping/unescaping of attribute names, or having to use some mapping from their natural names, to some different set of names that must be used in Rhino, due to this implementation detail.

If the xml parser is home-baked, seems a decent guess it may actually only have trouble with element names containing spaces (well, and angle brackets I suppose, though have not tested).

You’re probably right. I wanted to log these while I saw you mention it. Without the YT items it’ll all drown in time, especially now that people are on vacation (like myself).

1 Like

@jdhill does this work for you?



It seems good to me, but also a bit ambiguous, since it sounds like reserving the right to “fix” the current permissive parser behavior, breaking existing non-compliant content retroactively. So I’d also like to see it clarified whether developers have to worry about that.

This is important to me personally, because frankly, I want to use keys that fall slightly outside the stated spec, but which work fine, and I want to use them, especially given that the limitation will be erased in v8.

Sorry, missed this comment in the second link:

I've discussed this with Andy and we came up with the following solution:

    In V7, we don't change the behavior at all and just document that field names must be legal XML names.
    In V8, we introduce a new parameter block which uses the following format:

This is perfect, in my opinion.

Hi @jdhill,

Just to be clear, I didn’t change the behavior except in ‘Debug’. It’s just a bit more picky about firing an assert if it finds an illegal tag. This is for internal use as I understand that 3rd-party plug-in developers don’t see our internal asserts because the ‘Debug’ plug-in runs in ‘Release’ Rhino. So 3rd-party developers should not have to worry about this.


1 Like


Hi @jdhill,

This is fixed in Rhino 8. Would you be able to test that it does what you need?



Thanks John, I do not have v8 installed, but I can put it on my list of things to do and let you know.

RH-64873 is fixed in Rhino 7 Service Release 9