Re: [xsl] Specification of a transform.

Subject: Re: [xsl] Specification of a transform.
From: davep <davep@xxxxxxxxxxxxx>
Date: Mon, 09 Sep 2013 16:24:07 +0100
On 09/09/13 13:01, Geert Bormans wrote:
Hi Dave,

The way I interpreted your question is not "how to do the transform" but
"how to specify",
and regardless of the complexity, answer that question in general.
If that really is what the question was asking...
I would definitely be interested to see the answers

Yes, e.g. a manager specifies 'do this', what does the stylesheet writer receive?

I have not yet figured out a good standardized way myself. I have often come to a conclusion that writing the spec was as hard as just doing the transform, so "spec it out using XSLT" should not be regarded as funny as it sounds at first

Yes.... which leaves the question, have I or you done what the manager wanted?

There are so many factors to take into account: complexity of the models, complexity of the project as a whole, size of the project as a whole, who is doing the analysis (technical or less technical), is the specification part of a series of workshops, or just a loner writing out the spec, who needs to validate the spec, will the spec serve the testing environment, ....

But at the heart of it, here is an instance (or schema) please produce another instance (to another schema).

In general there are three mapping approaches I use, the method at hand chosen based on the parameters set in the previous paragraph - Word document, lots of text, structure of the word document usually following the structure of the source XML. Very ad hoc.

Yes, and quite likely a nightmare to write the transform?

Not my favorite.
Used most for communication with non technical Subject Matter Experts or
- Excel document: lots of columns if context needs to be expressed more
or less visually (subject matter experts or management). Less columns if
context can be expressed using XPath expressions (technical audience).
Used in most of my projects, still very ad hoc. The more complex the
mapping (small structural alikeness) the more descriptive this would become

Again, hard to generate a transform? I guess this leads to the obvious solution. The stylesheet writer goes back to the requesting authority
with all the questions?

- Unit tests driven (mapping by example?): my favorite. Mappings
expressed using small snippets of document as examples.  Not every
project has the resources or time to do that. But it is obvious that
there is a wider use in testing for the specification.

Which does leave holes? What of any intervening elements? Combinations which are not provided? Values which are not covered?

Whether there is one step or multiple steps is in my opinion not part of the specification, it is part of the development process

I hope this makes sense,


Yes... but it still leaves a big hole?
docbook to html. Relatively easy.
XXX to any 'display' format. Relatively easy.

XML to XML is the hard one IMHO.

Thanks for your thoughts.


At 09:42 9/09/2013, you wrote:
Given schema A as input XML. Schema B as XML output.
  Assume no hierarchical simple relationship.
  Assume mapping of values needed from input values to output values.
  Assume literals are needed.
How do (might) you specify the required transform?
How do (might) you validate that instance A has been correctly
transformed to instance B, assuming input and output are both valid to
the schemas.

Not something I've seen mentioned on this list?


Dave Pawson


Dave Pawson

Current Thread