At 2013-09-09 14:01 +0200, Geert Bormans wrote:
The way I interpreted your question is not "how to do the transform"
but "how to specify",
Why not both?
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
In July 2003 I published an environment named LiterateXSLT that is
still being used today by some people other than myself (in
particular a B2B solution from Italy that uses it to quickly
implement A-to-B translation XSLT transformations in a semi-automated
fashion). I followed that up in 2004 with another environment,
ResultXSLT, that doesn't replace LiterateXSLT but is complementary,
building on the first environment with modularization features. I
use that in my UBL stylesheet work, synthesizing XSLT stylesheets
that produce HTML and XSL-FO results without having to hand-code the
entire transformation.
http://www.CraneSoftwrights.com/resources/#literatexslt
http://www.CraneSoftwrights.com/resources/#resultxslt
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,
But what if the *act* of writing the specification was expressive
enough that the XSLT transformation could be synthesized. And, that
specification was testable as a standalone document.
so "spec it out using XSLT" should not be regarded as funny as it
sounds at first
Indeed, the germ of the idea is as follows: annotate a prototypical
result instance of "B" with signals that convey information about the
source tree "A", press a button, and out the other end is an XSLT
stylesheet that transforms instances of "A" into instances of
"B". So that Italy B2B company is given an example prototypical
target invoice XML document by a client, he annotates it with
information about the source invoice XML document, presses the button
and out comes an XSLT stylesheet that transforms instances of the
source into instances of the target. He then does the opposite,
annotating a prototypical instance of his existing invoice XML with
information about the client's XML, presses the button, and out comes
an XSLT stylesheet for the other direction.
What made me think about this approach was the knowledge that
foreign-namespace annotations in XSL-FO are ignored, thus giving me
license to annotate an XSL-FO prototypical result instance. I can
visually validate the XSL-FO prototypical result has the required
formatting objects and properties before creating the XSLT
stylesheet, then annotate it with the information needed to
synthesize the XSLT transformation.
Then I realized I could do the same with HTML or any arbitrary XML
... I've included some housekeeping stylesheets for those
vocabularies that are not tolerant of foreign namespaces.
Since an XSLT stylesheet is a collection of result tree templates in
template rules and other instructions, and the XSLT processor
assembles the result from the templates found in the stylesheet, then
just break up the prototypical result tree into templates and
template rules of an XSLT stylesheet.
At 09:42 9/09/2013, davep 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.
In order to get the templates needed for the synthesized stylesheet,
I decided to work from prototypical result instances rather than the schemas.
Not something I've seen mentioned on this list?
Look back at my previous posts regarding LiterateXSLT which started
as far back as February 2004:
http://www.biglist.com/lists/xsl-list/archives/200402/msg00769.html
... I've solved the generalization problems I posited then and
published what has been turnkey to use. The packages are downloaded
a lot, but I don't hear much from those who use them, unless they are
particularly excited about their success with it as is the gentleman
from Italy.
I hope this is helpful.
. . . . . . . . Ken
--
Public XSLT, XSL-FO, and UBL classes in the Netherlands Oct 2013 |
Public XSLT, XSL-FO, UBL and code list classes in Australia Oct 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ |
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers: http://www.CraneSoftwrights.com/legal |