• From: Gareth Oakes <goakes@g...>
• To: "Costello, Roger L." <costello@m...>, "xml-dev@l..."<xml-dev@l...>
• Date: Sun, 4 Aug 2013 00:40:07 -0700

On 4/08/13 5:46 AM, "Costello, Roger L." <costello@m...> wrote:


>Hi Folks,
>
>Below is an example of XML that looks on the surface to be well designed.
>However, when you go to implement applications to process the XML, then
>you realize that due to the way the XML has been designed it forces
>application code to be brittle and non-extensible.

Good example, thanks for sharing.

This seems a bit like the path I think most XML learners go down "why not
make a generic DTD?" where you have <element thing="value"> or
<element>value</element> and have value be the important thing you want to
test or switch against. The usual justification has something to do with
not having to update the Schema/DTD later down the track due to changes.

The penny drops when you realise schema/DTD is there for a reason and that
is to ensure you have valid content throughout the processing pipeline.

So then you end up with a schema/DTD plus a Schematron (eg. two-stage
validation). The first stage of validation ensures your XML is compliant
with the general structure that is required. The second stage  validation
is done per pipeline component to ensure that particular component (eg. a
proprietary XML consumer) can deal with each particular document. The
reason being is that it can be prohibitively expensive to code for every
possible permutation a schema/DTD allows, so instead you code for what is
commonly used, track that in the second stage validation, and catch the
exceptions as you go.

In your particular case it sounds like you have a few options. As you
point out, plain-text actions don't sound great, something like <Action
type="Replace"> might be the next best idea. (You also may not need a two
stage validation because XSLT allows design patterns which elegantly catch
exceptions during processing)

I do agree with Ken - it really depends on what you're trying to achieve.
The goal is usually automation and reducing workload on actual humans, so
let the system pickup the slack :)

-Gareth

• References:
  • Example of lousy XML design
    • From: "Costello, Roger L." <costello@m...>