Hi Ken.
On 09/09/13 15:20, G. Ken Holman wrote:
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?
Because many of us here can write a transform... I've not heard many
(any?) talking about specifying a required transform.
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
Is this 'output an XML instance to a display format'?
Do you agree this is easier than covering all bases of an XML to XML
transform?
The display might not please the customer / specifier, but you have
provided some visible output.
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.
<grin/> In an ideal world? Perfect.
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.
Automating the XSLT generation was not my intention.
What of covering values? E.g. in schema B,
a/b/c/d/text() is missing, or out of bounds - what should the transform
do? I can't calculate tax is the cost is not given .... etc.
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.
Generalising.
Take a schema B instance. Annotate each element with a source xpath,
perhaps schematron 'rules', any math etc for modified values,
Something else if the input units needed changing etc.
Something else if I needed to map input to output values......
So Geerts idea is still valid, mixing it with with annotations.
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.
If this is simply to 'specify' (for a person initially, perhaps later
for a machine) the transform, then I think it would cover most
eventualities Ken?
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.
There's a posh name for it, but isn't this basically a pull format?
with bells on?
Thanks Ken. I can see way working.
Where's Liam when you want him?
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--