Analysis Paralysis

Too much requirements gathering and analysis can lead to problems early on in a project.

Too much content analysis can lead to problems throughout the project. Improper use of namespaces or developing too detailed a DTD or Schema for your content model can result in the Rigid XML Mini-AntiPattern previously mentioned[BJ]. Many operations and features in your XML CMS, including specialized views of particular documents resulting from an XSLT transformation to HTML, inevitably rely on the content model's structure, assumptions, and decisions made during content model development. Inflexibility can kill the usefulness of your data structure, and downstream changes to your content model will ripple throughout your stylesheets and many other less obvious system components.

Developer

DTD and Schema development must be thorough to minimize changes that will ripple through stylesheets and other system components. However, to minimize impact of future structural changes, the structures should be designed to be flexible with points of extension. See Rigid XML for some good examples and related discussion[BJ].

Rigid XML

Architecture by Implication

System architectures that are not planned in advanced evolve as the result of coding decisions. This can result in a system with serious flaws and missing functionality.

Document Management Systems often serve as the core component of storing and managing data for corporate enterprises. To manage data at the content level, as opposed to the document level, XML Content Management Systems add several overlapping layers of complexity beyond mere document management. The additional features and functionality from integrating and combining standards behind an intuitive user interface can be a daunting task indeed. Add the final ingredient of the relative newness of the technology and the lack of long-term practical working knowledge of combining standards and you have a very fertile environment for 'Architecture by Implication'.

Standards are constantly changing and upgrading. This requires the vendors to continually update their products to comply with the new standards, while also continuing to provide new features and interfaces. It is enough of a task to simply keep up with the technology changes, much less be preventative and prolific about the implications and problem areas of integrating these standards over the already robust and flexible feature set provided by a Document Management System. It is unfortunate, but in this environment refactoring the fundamental architecture of the system as feature sets are expanded can easily be forsaken to meet deadlines and the other technical challenges presented.

See the 'Continuous Obsolescence' Mini-AntiPattern below for discussion relating to standards in a continuously changing environment.

Developer, Consumer

Whether you are developing or evaluating an XML CMS, the same universal truths holds true:

Poorly architected systems will almost certainly be missing critical system-level features (and may have been developed in a way that these features cannot be provided). Unfortunately, fundamental system underpinnings are not always obvious to those evaluating a system.

Several XML-related AntiPatterns are discussed in subsequent sections. They will provide some practical examples to help you recognize this type of problem.

Configuration Abomination, Continuous Obsolescence, Import Beast, Swiss Army Knife

Golden Hammer

Golden Hammer is a solution or technology that is applied to problems that it shouldn't be.

Bruce Tate's 'XML Misuse' is a specific instance of this antipattern [BJ]. XML is a powerfully expressive document format with many related standards that can be used to solve many, many problems. When it is applied in unappropriate contexts, bad solutions are developed and new problems are created. If data and requirements lend themselves to a table-based relational database, don't apply XML to encode it in a hierarchical structure. If a tool exists that quickly and efficiently solves a problem context, don't reinvent the wheel by solving it with XML unless you have a sufficient reason to.

Developer

XML is not a solution to all your problems:

XML Misuse

Stovepipe System

Legacy systems whose components and architectures do not fit well together lack the ability to be integrated into useful solutions. Many enterprises are stuck with a variety of these 'stovepipes', none of which meet their current needs, and very few of which properly communicate or interoperate with each other. Enterprises are starting to realize the implications of stovepipe systems and are turing to standards-based solutions to help solve this problem.

Properly architecting and integrating international standards into systems can reduce the stovepipe system risk. However, these will merely reduce the number of the potential problems. Lack of proper programming interfaces and the underlying architectures can still prevent tools from interoperating properly to provide real solutions. Fortunately, many vendors are also realizing that they can sell more of their tools if they make them interoperable with other vendor's tools that perform complementary features.

Developer, Consumer

When designing and architecting a tool or system, make interoperability a priority. The problem of stovepipe systems can be greatly reduced by developing an open, extensible system interfaces.

Fully support standards. Make the content your system outputs fully standards-compliant and open (as opposed to proprietary and hard for others to deal with). This will make your tool more marketable, more desirable, and more useful to your customers.

When evaluating a new tool or system, make sure that you evaluate its Application Programming Interfaces and other points of connectivity to understand how it fits into your chosen suite of tools. Understand the extent it supports standards. Does it support the one feature you really need, or every other feature of the standard except that one?

Stovepipe Enterprise, Vendor Lock-In

Vendor Lock-In

Vendor lock-in typically occurs when proprietary solutions are used on any business-critical data problem. At some point in time, all software tools are replaced by better, faster ones. If a CMS does not make it easy to export your data, knowledge, configurations, and other business critical information in an open format that can be parsed or quickly converted into/used by a new tool, then you are stuck in vendor lock-in. When a significant amount of time, money, and effort has been invested into a particular tool or solution, vendor lock-in is increased.

Regardless what type of tool is under consideration, you should be aware of whether or not this tool will lock you into a particular solution, data format, or company. XML CMSs and tools that fully support standards can minimize vendor lock-in.

Consumer

Full support of a standardized data format will help keep most of your data from vendor lockin. However, any deviations from standards conformance will lock you into a particular tool more and more. If a tool provides features that replace less-useful standard-conformant ones, there is a trade-off to be made.

Any custom features will also lock you more and more into a particular tool. Do these custom features output their information in a standard or proprietary format? Does your use of the tool require you to rely on that tool's exclusive features or architecture to solve your problems?

Some degree of vendor lock-in is inevitable on any large scale solution. However, you should keep these things in mind when evaluating a tool so that you are truly aware of the degree of your vendor lock-in and commitment.

Several XML-related AntiPatterns spawn from this one are discussed in subsequent sections. They will provide some practical examples to help you recognize this type of AntiPattern.

Boat Anchor, Stovepipe Solution/Enterprise, Trusting Souls

Boat Anchor

Often costly technology components must be purchases as part of a system. If these components go unused, or provide minimal value, they are boat anchors and should be avoided.

No single technology or tool will solve all of your problems. In environments of relatively new technologies and standard implementations, many companies have no choice but to use tools and services provided by other vendors to complement their own feature set and meet your needs. This can be a frequent occurence with XML CMSs. A typical example of this is an XML CMS that will require installation and usage of a particular XML database or Web Application Server (for its web portal)

Consumer

When purchasing a tool or system, look at the other purchases required for this tool. Each of these other purchases could potentially be a Boat Anchor that should be money better spent making this new tool meet your specific needs. A Boat Anchor can often be identified as a required tool that is still under development (for its first release) or that is required to meet a primary CMS feature that is under development. A Boat Anchor may lead you into vendor lock-in that you have not accounted for.

Vendor Lock-In

Continuous Obsolescence

Continuous Obsolescence occurs when technology updates occur so frequently that it isn't possible to keep up with and integrate all necessary changes.

XML has over one hundred related standards. The more standards your tool or CMS supports, the more effort (and the more complexity related with that effort) is required to keep up with rapidly changing standards. Frequently, as the number of supported standards grows, the amount of time to keep each up to date and fully supported shrinks.

Developer, Consumer

Fortunately, the common base standards used by XML CMSs, including XML, DOM, SAX, XPATH, XSLT, and DTDs, are tried and proven. Tools that use these standards can provide a tested baseline without having to keep up with every new update to each one. Newer standards such as XMLNamespace, Schemas, XQuery, TopicMaps are more likely to be less tested, less understood, and require updates to the latest releases to correct design flaws as they are encountered.

Consider using many smaller tools that perform well-scoped/specific tasks in your process, as opposed to one comprehensive tool that tries to meet all of your needs. It is more likely that each smaller-scope tool can keep up with the related standards to that tool, and thus all tools in your process will be up-to-date. However, there is a tradeoff. Using many smaller tools can be much more costly to integrate and develop a comprehensive solution.

At any rate, using open standards-based solutions will provide more consistent value than stovepipe systems under the same conditions of continuous obsolescence.

Architecture by Implication

Smoke and Mirrors

When production quality does not match demonstrated features, this is Smoke and Mirrors. What you see is not always what you get.

It is unfortunate, but whether you are buying a car, a computer, or any software system for any technology, trusting persons may fall prey to a Smoke and Mirrors routine.

Consumer

Critical/key features should be examined through hands-on evaluation to detect fragility. These features should be double-checked against APIs and other documentation provided to assure it indeed does what you have been shown. Hands-on evaluation also helps prevent the similar 'Viewgraph Engineering' AntiPattern in which documentation for a product is comprehensive, but doesn't match the end product.

Trusting Souls, Viewgraph Engineering

Swiss Army Knife

When a particular tool component appears to address every possible solution to every possible problem, it is likely a Swiss Army Knife.

The Swiss Army Knife can be a clear indicator of Architecture by Implication. Initially, a particular component may have had a well-defined architecture, that over time has been repurposed and extended without proper rearchitecting. This AntiPattern may be non-obvious due to a proprietary language that hides APIs and serious design flaws.

Consumer

Look at API documentation. Confirm that there is a logical separation of functionality into classes and components. If one class appears to provide far more options and features than could possibly ever be needed, this may be a Swiss Army Knife. This may not be a critical problem. However the more occurrences of SAK in a system the more likely it is that the system wasn't well designed, thought through, fully tested, and may result in Walking through a Mine Field.

Swiss Army Knifes may be hidden behind custom query and scripting languages.

Architecture by Implication, Walking through a Mine Field

Walking through a Mine Field

Software will always have bugs. These bugs can be devastating. Good testing prevents bugs. Using poorly-tested software can be like 'Walking through a Mine Field'.

Once again, whether you are buying a car or a piece of software, if it is not properly tested, it can have devastating results. Where the auto industry has mandated safety and other testing, software doesn't always. Many XML-related standard define testing that must be performed to verify true conformance. However, this does not extend to tools and solutions based on them. There are also no severe consequences to claiming false conformance.

There is no guarantee that the software you are buying has been rigorously tested.

Developer, Consumer

Ask what testing process is used for the tools you are evaluating. Ask the engineers, if possible, and listen for keywords such as test-first development, automated or unit testing, regression testing, system testing or standards conformance testing. If you do not get an answer you like, then hands-on evaluate features of the tool that you really need.

Swiss Army Knife, Wolf Ticket

Wolf Ticket

A Wolf Ticket can be thought of as a wolf in sheep's clothing. A Wolf Ticket is a product that is sold as conforming to standards, that does not fully conform and thus you may not get all of the expected benefits of that standard's features. It is not uncommon to assume that because a feature is listed in a checkbox, that it works the way you would need it to. It is also not uncommon to assume that support for open source standards implies 'full conformance' of those standards. This is not always the case.

The Wolf Ticket is a sincere concern when purchasing any product based soley off of its standards conformance. As discussed in Walking through a Mine Field, there are standards conformance tests. However, there is no guarantee that the product has been conformance tested. A wolf ticket can be an authoring tool with full XML support that lack support for linking standards. A wolf ticket can be an XML CMS that claims support to XML, yet will not allow the use of relative system pathing, or claims to support linking standards but really only supports ID/IDREF linking and doesn't actually use them for its default linking mechanism. Another frequent wolf ticket is a claim of full internationalization support. Refer to the new XML CMS AntiPatterns 'Versioned Linking Dilemma' and 'Internationalization is Fully Supported' for more information.

Consumer

Wolf tickets are often not intentional and are not by design. It is the responsibility of the consumer to: 1. understand the 'extent' of support for each standard in a product, 2. not make assumptions (such as that both DTDs and Schemas are supported), and 3. confirm that conformance tests have been run for the key standard items that the system was purchased for.

Vendor Lock-In, Versioned Linking Dilemma

Import Beast

The import should be done by tomorrow morning, if nothing goes wrong this time...

Performance during import and export; conversion of XML data to/from database.

When an XML CMS is importing a new document a number of factors can significantly affect the performance time. These factors include: the underlying database technology used, the conversion algorithms, the number of transformations, cross-linkings and referenced meta-information for the document, partial or sub-document object creation, and indexing.

Relational and object databases are typically the database technologies used. Each has its own set of unique benefits and drawbacks.

Relational databases are a stable and proven technology. Many commercial relational databases exist and have withstood heavy loads and usage. Unfortunately hierarchical data doesn't necessarily map well to table based data. It can take significant effort to map heirarchical documents, such as XML into relational tables in a way that is performant and handles under load. In order to provide the transformation and storage of data at import and export time, this can be a 'serious' performance inhibitor. It is also worth mentioning that if the data storage mechanism was designed to work optimally with a particular relation database, it may be possible to use it with other relational databases through JDBC/ODBC, however bizarre side effects may be encountered due to different limitations of each one.

Many companies opt for a custom Object database technology. The downsides to this are that it is a new and often non-standard database technology. It could use simple file areas to store content or it could serialized data in any number of storage mediums. As this isn't a relational database, it likely doesn't use a widely used query language, such as the Sequel Query Langage (SQL). It could be a prototype of a new standard, such as XQuery, or a custom extension language. Each has its own benefits and performance drawbacks.

It is also important that you consider actual import and export usage scenarios, as opposed to single file import and export times.

Consider this scenario:

Regardless of the underlying technology, attempt to make sure it is stable, reliable, performant, and transactionally safe.

Finally, keep in mind that the exports also depend on the query language used to retrieve and rebuild the data. Depending on the algorithms used internal to this query language, certain operations can have heinous performance that only occur under certain, less common circumstances. An example of this could be link transformation or resolution of circular linking and dependencies on sub-document content modules.

Do not assume that import performance will be acceptable.

The following performance tests will help identify if this problem exists.

Compare the import and export time of XML and structured documents to plain text and binary files.

Compare the import and export time of 10KB, 100KB, 1MB, 10MB, and 50MB XML documents into the database. Graph and summarize the results.

Compare the import time of XML documents with a variety of characteristics, such as a large number of elements with little text vs. small number of elements with a lot of text.

The goal is to identify content situations that will significantly impact performance that may not be obvious. These will vary depending on the CMS chosen.

Quick test: import a 10MB XML document and calculate total time.

Perform these tests with multiple concurrent clients (based off of your expected number of end users) to determine scalability affects on performance.

The RAM requirements for importing large structured documents can also be a significant issue. It has been experienced for an XML CMS to have a heap size growth factor of 100 per 10KB while importing a document.

Severely decreased import time under heavy concurrent user loads.

Unreasonably large import times for structured documents (XML, SGML, etc...):

Unreasonably large RAM memory footprint when importing or exporting documents.

The import and export times will potentially affect editor integrations and general performance of system operations that require processing of structured documents. The cost and time of refactoring the underlying system architecture is prohibitive. The end result is a system that will almost never meet end user needs.

Lack of knowledge or experience with the problem domain.

Poor architecture, design, and implementation of data storage and related processes.

Lack of extensive document testing.

If requiring all end users to have 1GB of RAM for import and typically waiting until the next day while a large group of document imports is an acceptable end user scenario for you, then ignore this AntiPattern.

There is no one root cause for this category of problems. Likewise, there is no one solution to the causes of this category of problems.

As a consumer, the solution is to evaluate the import performance using the tests above relative to your expected user situations and factor the results into which product you choose.

As a developer, the solution is to identify the problem areas and refactor the architecture of your data storage system to reach an acceptable import time baseline. It 'should' be safe to assume that total import time will be acceptable regardless of what the size, content, and other factors surrounding the import of an XML document. Work to make it so, and when it is post your results with pride.

Architecture by Implication

Configuration Abomination

There are so many configuration options that the engineers can't remember them all and disagree on what exactly each one does.

These two installations are identical, why don't they both work?!?!?

WARNING - DON'T EVER CHANGE THIS LINE (Excerpt from configuration file).

Installation and configuration layers.

Document Management Systems have a fairly standard set of configuration options. Based on the feature sets, the configuration options will vary for each product. However, you can expect to see the same types of configuration options for basic versioning, data storage, access controls, etc...

XML Content Management Systems are a completely different breed. Each integrated standard and each new revolutionary solution type (reuse, hyperdocuments, linking) presents its own set of configurations that will radically vary depending on the user groups that were analysed or targeted during the product's conception. When these sets of configuration options are generalized and extended for new end user requirements, the end result can be a configuration monstrosity that only its creator could love (or hope to understand).

Configuration Abomination occurs when a system either has 1) so much configuration that its confusing or 2) configuration occurs in uncommon places.

The former can be discovered by simply looking at how the system is configured (text files, User Interfaces, XML documents). Do the configuration options in the installation and administrative manuals make sense? Are the configuration locations and options even detailed in the provided manuals? The configuration for each major system component should be examined.

The latter can be much more difficult to detect. For each of the components, does the location of where a feature is configured make sense? If the wrong features are configured on a client, as opposed to a server, simple changes can have nightmarish side-effects.

The documentation shows configuration options for every possible scenario, a veritable Swiss Army Knife of configuration.

Some options prevent others from working.

Some options haven't worked since the last release version.

End users may have the ability to configure things that they shouldn't.

Some degree of Configuration Abomination cannot be avoided due to the sweeping scope and nature of the problems being solved by an XML Content Management System.

However the consequences can be significant. Performing identical installations can require a lot of manual changes. Users can often have access to configuration items that may allow them to break fundamental system components. Everything those users do until the problem is identified and resolved can ripple through the system making it very difficult to recover the system, much less understand and track the affects.

Configuration is often developed and exposed as needed, as an afterthought to the primary system features. Configuration Abomination can grow to a frightening level before it is ever detected. Too often the (improper) quick-fix solution is a note 'WARNING - I don't know what this does, but don't ever change it!!! - John Doe'.

Configuration issues are an inevitability. Not dealing with them is unacceptable.

The solution to this is to include configuration as a major system feature. As new product versions are released, a conscious effort to re-analyze and refactor the existing configuration options must be performed. Otherwise the number of configuration options will continue growing, exposed in an unorganized fashion, never to be removed, and eventually becoming a feared creature that is avoided at all costs, yet never actually put to rest. It is vital to re-evaluate the need for existing configuration options as well as their locations and permissions to prevent this AntiPattern.

Architecture by Implication

Control Freak

We have a custom language and XML configuration files, so every system operation can be performed without needing a programmer.

The current functions (in our language) meet all of our existing customer's needs. You won't need anything else.

Customization and use of advanced system features.

Take fair warning, if a product has a custom language for interacting with the system or its database that doesn't have equivalent APIs in a common programming language, it 'will be' costly to use, customize, and maintain.

This is referred to as Control Freak, as all of the control in the system is constrained to the language provided. Too often these languages were Architected by Implication and have been expanded on an 'as needed' basis.

Unclear APIs and points of extension.

'Comprehensive' custom language missing features you don't know you need yet.

Features that sound too good to be true, often are.

If there aren't user interfaces wrapping most of the custom scripting language, you most certainly will need a programmer to make it do everything you need. If you at any point need to implement custom workflow or other more complex processes, you will need someone who understands architectures and concepts that hide complexity, provide the needed security, etc... When there isn't a solid underlying architecture that provides equivalent stable programming language APIs for key system operations, then you are in a big world of hurt.

When this happens, what options do you have? You will have little alternative than to pay that company money to extend core features (that probably should have been present in the first place).

Wolf Ticket mentality.

Ignorance to technological advances.

As a developer, accept the technological advances of the last 10 years and expose programming interfaces and extensions in place of your custom language. Keep the custom language to hide complexity from end users, but don't hide the fact that it will take a programmer to understand and properly use your language. Refusing to do so is a recipe for failure and disappointment.

As a consumer, evaluate the custom language for complementing features. Confirm claims that sound too good to be true. If it says that a programmer is not required to use the features, then regardless of who you are, you should be able to understand and use it, right?... Look for APIs and points of extension, in case you will need a programmer to change system features.What languages are supported for those APIs and points of extension? Are they fully supported, or are they fixed to particular language verisons or other constraints?

Wolf Ticket, Vendor Lock-in

No Love (for ENTITYs)...

Where are my graphics? Why don't they show up in the HTML or the Editor?

There are 200GB space on the image storage drive, why is it full?

Entities get no love. XML, SGML, and related standards commonly use ENTITYs to reference graphics and images in documents.

Each authoring tool has its own configuration for locating images. If that tool and its configuration isn't integrated with the CMS's repository to either auto-import/export referenced ENTITYs or that repository doesn't expose images via a URN/URL, then the editor cannot retrieve those images for viewing. If the editor allows you to open XML documents, yet uses its own proprietary format that allows encoding of images into the binary of those documents, then exports back into XML can have a mix of results that turn an author's job into a nightmare.

If the XML CMS has a web portal, similar interface, or transformation of XML content into HTML or another format, then ENTITYs cannot be overlooked. If the CMS's repository does not expose he images via a URN/URL, then the HTML (or equivalent) cannot retrieve those images for viewing.

In either of these scenarios, images are required to be stored in a file location available to all authors and web clients. The XML CMS has a versioning repository. Why shouldn't it control and version the ENTITYs as well as control their external availability?

If the repository does indeed import entities and make them available via a URN, your problems still aren't all solved. When you import new versions of a document or other documents that reference the same graphic, how does the repository let you configure this? Will it import a new graphic file every single time? You might be suprised.

Once the system has imported graphic ENTITYs associated with many documents, what facility does it provide to manage the references? This can present complex identification referencing issues similar to those of hyperdocument management and is often overlooked or left to solve later. After all, customers purchase XML CMSs for its XML handling, who's going to doublecheck how it handles and manages images...

This AntiPattern represents a set of related ENTITY problems. The underlying cause is typically the fact that ENTITY management is not a key selling requirement, and can therefore be under-analyzed or overlooked. Proper use of XML standards allow for separation of content from formatting. This also provides separation of XML text content from image and graphical content such as JPG, GIF, TIF, and BMP files. While many XML CMSs do a very thorough job of managing and processing XML text content, oftentimes there is insufficient or no management for the ENTITYs referenced in these documents.

The problems that have been experienced are:

Authoring tools 'new' image reference id generation not configurable.

Poor or missing ENTITY management interface.

Editor tool not able to reference images in repository.

HTML portal view not able to reference images in repository.

New image imported each time you import the same XML document.

Inability to reference same graphic object from multiple XML documents.

Lack of sufficient ENTITY management, both at import/export time and while in repository, can lead to a new image being imported for every new version of the same document and every other document that should be referencing the same images. This can lead to very poor disk usage and thus quickly running out of storage space.

Lack of URN/URL exposure for locating and retrieving images from the repository will cause additional and often significant management overhead for images in authoring tools, transformations, and web portals. This in turn can lead to either missing or wrong images showing up in the wrong documents.

A series of related problems making authoring end users quite unhappy.

No image URN exposure for images from repository.

Poor or non-existant import/export time configuration for ENTITY reuse/referencing.

Export of related graphic ENTITYs at XML export time.

The underlying cause is typically the fact that ENTITY management is not a key selling requirement, and can therefore be under-analyzed or overlooked.

This AntiPattern may be ok if it is understood that all graphics, images, and other ENTITYs will always be managed externally to the CMS. Keep in mind, if this isn't managed in and by the repository, it may lead to:

An XML CMS should provide quality ENTITY management. It should expose files via URN/URL or similar to allow referencing from authoring, web, and other clients. It should include configurable options for image import and export of ENTITY references for single XML documents, subsequent versions of single XML documents, and multiple different documents. These options should include: replace existing image, increment existing image versions, and import as a new file. The CMS should also provide reference configuration changes for files already in its repository.

(The) Trusting Souls

Standard X is fully supported...except for feature Y.

As the number of supported standards in a CMS increases, the amount of time spent keeping each up to date and fully supported decreases.

It is inaccurate to believe that every aspect of each standard 'supported' in a CMS is fully supported. Every detail of each standard will not be implemented. Some custom features will replace less useful standard components, such as replacing non-directional associations in Topic Maps (XTM). In some cases it is simply not possible to implement every detail of each standard. Certain aspects of a standard may not relevant to the context it is being applied.

It is advisable to know the extent of the support for each standard supported by a XML CMS...and avoid being one of the Trusting Souls who gets burned.

Identify and test the standard features that you are truly utilizing.

Linking support and more advanced standards are frequently less supported than the basic ones.

Beware of features that are still being completed that will utilize the standard items that you need.

Assuming Unicode and other internationalization support is complete for the system features you will be utilizing.

Lack of support will become apparent when you actually try to use the features in question.

The few key standard items that you really need may not be fully supported.

Lack of time.

Standard item not useful in the context it is applied.

Conflicts between standards and or system features.

Scan the provided documentation for warning signs, such as use of relative SYSTEM paths in documents will break IMPORT/EXPORT mechanisms. You may (and very likely will) be suprised at the extent of standards truly supported by the tools you are going to use. If you don't know, find someone who knows what to look for.

Internationalization is Fully Supported, Vendor Lock-In, Smoke and Mirrors

Internationalization is Fully Supported

Internationalization is Fully Supported by this tool (insert laughter here).

Support for Unicode does not imply full support for internationalization.

Unicode is only one aspect of true internationalization. Internationalization also has affects on how documents are searched, processed, rendered for view, and many other XML CMS features. Each XML CMS has a separate set of features. Each feature must fully support internationalization for the system itself to make this claim.

The standards that form the basis for the existence of XML Content Management Systems fully support Unicode. Many of the underlying parsers used in existing XML CMSs fully support Unicode. Unfortunately, XML CMSs themselves do not. Part of the problem is that (to my knowledge) the required criteria for 'full support for Unicode' in an XML CMS is not formally defined.

Another aspect of internationalization support relates to either authoring tool integrations or publication to HTML (or other formats) for a web portal. Some unicode languages display right-to-left, as opposed to left-to-right. Some have other unique heuristics that determine display characteristics. Then there are indexing and search engine support issues, pattern matching and document processing issues.

Perhaps an XML database alone could make the claim of full Internationalization support as of today, but a comprehensive XML CMS solution could not.

The extent of Unicode and other Internationalization support in existing XML CMSs seems random at best.

Create two sample XML documents. Populate one with a full range of UTF-8 characters. Populate the other with a full range of UTF-16 characters.

Import each document. Export each document. Compare the files for equality.

Test various features of the authoring integration.

Test the publication to web features, to the characters appear properly.

Test the indexing and text search engine features. Do they let you enter special Unicode characters in the search strings, much less search for them?

User interfaces that perform dynamic conversion to other languages have been experienced to miss some less-used UI screens, or fail to convert all text on a display to the appropriate language.

Seemingly random side-effects and failures related to Unicode character content.