Actually, there is considerably more flexibility in data representation than this title implies, but underneath the hood there is one way to store the content of a card.  Different databases will have different capabilities to deal with large objects, and the default mysql implementation limits the content size to 64K, but abstractly it is not size limited.  It is text data, and might not respond well to storing nulls, and adopting international character encoding standards, it is multi-linqual text in UTF 8 encoding.  That doesn't mean you can't store objects, and common formats such as XML, JSON or YAML are essentially text based and are supported well by card formatters.

None of the common formats really support references directly, which makes the usage and syntax of coding links into text or objects another important axis of flexibility.  As with everything about the card model, this coding is specific to sets of cards, so type based encoding/decoding of data formats and links is used in implementing basic types and features.  Any content may be processed for references, and there is a modular parser that matches chunks, that are internal (name based) or external (typically URIs) links.  This parsing feature impliments comments and literals so I can show {{inclusion}} syntax without processing it.  The developer might use this feature for other types of content processing or translation.

In other words, the architect can use a wide range of representations for content and parse references however desired according to sets the system specifies.  There is also a standard parser to be used and customized.  It is used to implement the standard linking and inclusion syntax described below, and it is flexible enough to be used to implement a lot of other features we never thought of.