sub-elements with empty context vs. element text

[DrDavey]

What are the advantages/disadvantages of using a choice of a several
"sub-"elements with empty content (and no attributes) vs. simple
content. Here's an example:

Using simple content:
<process>xyz</process>

Using empty content sub-element:
<process><xyz/></process>

Assume in both cases the xyz part has a limited domain, i.e., it can
be xyz, abc, or efg, but no other values make sense. Of course some
day, I might want to extend it to include rst.

The XML Schema for the empty content sub-element version looks
something like this:

<xsd:complexType name="ProcessType>
<xsd:complexContent/>
</xsd:complexType>

This defines ProcessType as having empty content. I can then use this
to define the types of processing I want to allow as follows:

<xsd:element name = "process" type="ProcessChoiceType"/>

<xsd:complexType name="ProcessChoiceType">
<xsd:complexContent>
<xsd:choice minOccurs="1" maxOccurs="1">
<xsd:element name="abc" type="ProcessType"/>
<xsd:element name="efg" type="ProcessType"/>
<xsd:element name="xyz" type="ProcessType"/>
<xsd:element name="extented_process" type="ProcessType"
abstract="true"/>
</xsd:choice>
</xsd:complexContent>
</xsd:complexType>

The abstract element extended_process is added to permit extension.
Then I can add new types of processing as follows:

<xsd:element name="rst" substitutionGroup="extended_process"/>

The XML Schema for the simple content version would replace the above
definition of ProcessChoiceType with the following:

<xsd:simpleType name="ProcessChoiceType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="abc"/>
<xsd:enumeration value="efg"/>
<xsd:enumeration value="xyz"/>
<xsd:restriction/>
</xsd:simpleType>

My understanding is the only way to extend the enumeration is to
define a new type, NewProcessChoiceType, using a union. However, I
don't know of any way to change the declaration of the <process>
element to use this new type.

So my initial analysis is that the empty content sub-elements are more
extensible. However, I've only been seriously studying XML Schema for
about a week. So I'm looking for guidance on these two choices. I
understand that a third alternative would be to use an attribute,
e.g., <process name="xyz"/>, but I don't think I can restrict the
domain of the name attribute using XML Schema, which defeats the whole
point of this discussion.

Thanks in advance for your opinions.

[Joe Kesselman]

It depends entirely on what you're trying to express.

Think about the semantics of the document. If the value is something
which really is a single value _conceptually_, but which may at some
point in the future want to carry additional sub-structure, make it an
element. If it's a simple text value and will never be more, make it
textual content, or -- if it's a characteristic of its containing
element -- possibly an attribute value (leaving the possibility open of
other attributes and/or content to be added later).

Look at other XML-based languages which solve similar problems and
decide which make the most sense for you.

And, as with any design skill you're still learning, resign yourself to
the fact that you're going to make some mistakes and have to do some
redesign until you develop a sense of style and the ability to think in
terms of larger patterns. Consider creating an initial version, working
with it for a while, and deciding whether you like the way it behaves
before you let it get cast in concrete.