I need an XML schema with an enumerated type which allows wildcarding.

Question

I want to define an XML schema which allows elements like this:

<Element>TYPE1</Element>
<Element>TYPE2</Element>
<Element>TYPE3</Element>
<Element>Any Other Text</Element>

In this case, TYPE1, TYPE2 and TYPE3 are enumerated strings. However, the schema also allows any text content in Element.

This seems like a strange restriction. Here is why I want the type to be a pseudo-enumeration. I want it to be an enumeration so that autocomplete (called intellesense in Visual Studio) will work in XML editors. However, the enumeration list isn't a hard constraint because the software (Java) ingests the XML document using JAXB and is robust to values that aren't enumerated.

I can provide more details if they are needed.

Answer 1

As far as I know, there isn't a way to accomplish what you are trying to do. Enumerated type restrictions in xsd's are hard constraints. Otherwise, you would be using an xsd:string type which doesn't have any restrictions.

Answer 2

The short answer is, as btreat already said, that this ain't possible - nor in schema not in any other formal description of content (that I can think of)).

How would you imagine it to work? Schemas are formal, restrictive, documents that describe content (which can be validated based on that description). Enumeration is based on assumption that the values are known and well defined. If you add a wildcard option (in case of schema it could be xsd:string) then whats the difference between the wildcard and the enumerated values form validator perspective? Thus it's forbidden by design.

The only similar structure, and only in programming languages not content descriptors, to what you propose is a switch statement with default block but it's purpose is different - it defines alternative execution paths rather then alternative content.

---

In case of requirement to validate different values accumulated over time I would keep older schema and document versions and have each version valid with it's corresponding in time/version restrictions. Thus new documents will always be valid with current schema and you retain the ability to work (and check) older ones if need arises.