Today's version of the Recommendations page suggests an extremely limited set of characters for names:

It is recommended that resource types, attribute names, and association names be "dasherized"; i.e. consist of only lower case alphanumeric characters and dashes (U+002D HYPHEN-MINUS, "-").

I can see the virtue of this for attribute names, where any other punctuation might collide with the multitude of ways of specifying paths (dot-nesting, URIs, JSON Path, et cetera). But I'm having trouble with it when trying to map type names to their concrete representations in other languages — in particular, it gives no room for namespaces or inherited subtypes.

My real world example is this: we have a Ruby abstract class called Segment which represents a set of customers. By itself it makes sense, and if no specialization were needed I could call the JSON API type "segments" and be done with it. But we have different kinds of segments. Some segments are broken out by demographics or purchase history. Some of them represent lists in third-party service providers such as MailChimp. These usually have additional properties and behavior — classic inheritance, in other words.

For reasons that are debatable but out of scope, we're often using namespaces to indicate the class relationships. So there's a Segment::AgeRange and a Segment::NeverPurchased and a Segment::MailChimpList and so forth. It'd be swell if the JSON API type alone were sufficient to inform the client what kind of object to construct, and the fully qualified name is necessary. (We have other kinds of MailChimpList in our third-party service wrapper; we're not just namespacing for fun.)

So the question is, what to call the types? Off the top of my head I can think of a few options:

1. Ignore the problem. Call the types "segment-never-purchased" and so forth, and rely on external knowledge to map that to the actual class. This presents some maintainability issues, to put it mildly.
2. Overload the hyphen, allowing multiple hyphens in a row to represent a namespace separator. This has a couple of problems:
   1. The name "segment--never-purchased" looks ugly to me. And while that isn't a technical issue, I'm the kind of programmer who gives out The Pragmatic Programmer as gifts and believes in my gut that aesthetics matter. Stop caring about elegance and you'll stop noticing broken windows.
   2. The double-dash has other kinds of implicit meaning in some of our representations, e.g. Markdown documentation, where it often gets automatically converted to a long em —. We're using Apiary and API Blueprint, so inconsistent Markdown behavior is a technical issue.
   3. I only noticed this while typing the above two paragraphs, but my Mac really loves to auto-correct -- to — whether I'm in code or prose, and I have to work kind of hard to stop it. I could turn that off, but then someone else will have the same problem and not notice it.
3. Call them all "segment" and let some other field specify the subclass. In other words, the type is no longer the complete type. Bleh.
4. Ignore the recommendation and use some other punctuation, like a colon or a tilde or something, and don't make a Mountain out of a class Molehill < Mound.

Out of all of the above, I'm leaning towards #4, but I wanted to ask first in case anyone has any better ideas or has also encountered and solved this issue. (Or perhaps, as a longshot, felt the issue might be interesting enough to consider accommodating in the recommendation. Hubris, I know.)

Thoughts?