recommended approach is to create them by defining relational tables, generating XML-schema code, and then dropping these tables. This is problematic in many production operations involving dynamic schemas, where new attributes are required to be defined by power-users who understand a specific application domain (e.g. inventory management or biomedicine) but are not necessarily programmers. By contrast, in production systems that use EAV, such users define new attributes (and the data-type and validation checks associated with each) through a GUI application. Because the validation-associated metadata is required to be stored in multiple relational tables in a normalized design, a GUI application that ties these tables together and enforces the appropriate metadata-consistency checks is the only practical way to allow entry of attribute information, even for advanced developers - even if the end-result uses XML or JSON instead of separate relational tables. The server-based diagnostics that result with an XML/JSON solution if incorrect data is attempted to be inserted (e.g., range check or regular-expression pattern violations) are cryptic to the end-user: to convey the error accurately, one would, at the least, need to associate a detailed and user-friendly error diagnostic with each attribute. The solution does not address the user-interface-generation problem. All of the above drawbacks are remediable by creating a layer of metadata and application code, but in creating this, the original "advantage" of not having to create a framework has vanished. The fact is that modeling sparse data attributes robustly is a hard database-application-design problem no matter which storage approach is used. Sarka's work, however, proves the viability of using an XML field instead of type-specific relational EAV tables for the data-storage layer, and in situations where the number of attributes per entity is modest (e.g., variable product attributes for different product types) the XML-based solution is more compact than an EAV-table-based one. (XML itself may be regarded as a means of attribute–value data representation, though it is based on structured text rather than on relational tables.) Tree structures and relational databases There exist several other approaches for the representation of tree-structured data, be it XML, JSON or other formats, such as the nested set model, in a relational database. On the other hand, database vendors have begun to include JSON and XML support into their data structures and query features, like in IBM Db2, where XML data is stored as XML separate from the tables, using XPath queries as