My primary issue is with minimizing the number of different document types
we have flying around. We'll create attributes now and two or six months
later decide that going forward we actually need a structured value.
Sure, we could migrate the unstructured values to the structured values,
but we don't want our users having to constantly unlearn old syntax to
learn new syntax. The idea behind starting with element content rather
than attributes is to design an extensible document type to which we can
add new element types without having to keep changing old element types.
So our experience is that we've been burned by making something an
attribute that ultimately needed to be element content, but we haven't yet
been burned by making something element content that should have been an
attribute.
Besides, the attribute normalization rules that XML specifies have
occassionally caught our engineers off guard. Sometimes we need whitespace
to be significant in attribute values.
But the conciseness of attributes in elements remains very enticing, so
whenever we're certain that a value will forever fit into an attribute,
we'll put it there.
I'll grant that if you new that a document type would not evolve -- if you
knew that the requirements were fixed and unchanging -- then you could
partition data among attributes and content using whatever criteria you desire.
-- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370