Re: Somewhat offtopic: xsl question

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2004-05-27 23:16 +0100, Pedro Alves wrote:
>     I'm even a bit shamed to say that my solution is as simple as :
>
>     <xsl:template match="/in:Invoice">
>         <!-- Cabecalho -->
>         <xsl:call-template name="Header"/>
>     </xsl:template>
>
>     <xsl:template name="Header">
>
>         <!-- Unique identifyer -->
>         <xsl:text>UNH+</xsl:text>
>                 <xsl:value-of select="in:ID" />
>         <xsl:text>+INVOIC:D:93A:UN:EAN007'&#10;</xsl:text>

Nothing wrong with using the text output method!  There is no need at all 
to feel even a bit ashamed.  That was one of the approaches that I included 
in my question to you.

>     If there are better ways to do this I really would like to learn them.
>I have very little experience in XSLT.

When I want to put out a non-XML format, I usually do it in two 
steps.  There is a diagram of these two steps on page 32 of the free 
download excerpt of my "Practical Transformation Using XSLT and XPath" book 
that can be obtained at any time from the "Books & free excerpts" link in 
the marginalia of our home page.  Download the "Hyperlinked 1-up version" 
PDF file and go to page 32 titled "XML to binary or other formats".  Note 
that the page numbers in the index are all "hot" and hyperlinked into the 
text, and the bottom of every page has 26 hyperlinks into the index.

But what I want to describe below starts on page 32.

I note that in your template rules you have a lot of delimiters and 
hard-wired information in the EDI messages, plus you have to address stuff 
like line ends.  The first step is to divine a level of abstraction that 
will make sense for your applications generating the EDI message content 
without needing to know the EDI message structure.

What if you created PML (Pedro's Markup Language) to express the semantics 
of an EDIFACT message in an XML syntax:

      <PInvoice id="" date="">
         ...

Then you write a "Step 2" process that reads PML and writes the raw syntax 
of EDI ... this could be done in a programming language using SAX or even 
in XSLT:

      <xsl:template match="PInvoice">
         <xsl:text>UNH+<xsl:value-of select="@id"/>+INVOIC.....

Perhaps that is too high an abstraction and instead your PML would be:

      <EDIMessage header="" id="" date="">
         ...

...with a template rule:

      <xsl:template match="EDIMessage">
         <xsl:text>UNH+<xsl:value-of select="concat(@id,'+',@header)"/>...

With step 2 done and debugged, you've solved the low-level headache of 
producing the actual syntax.

Then all you need to do is step 1: worry about mapping the semantics behind 
the syntax of UBL to the syntax of PML, since PML will handle the syntax of 
EDI.

     <xsl:template name="in:Invoice">
        <EDIMessage header="INVOIC" id="{in:Invoice/in:ID}"...

Having written a single PML interpreter, you can have multiple stylesheets 
for different syntactic expressions (vocabularies) of different e-Commerce 
semantics and just produce PML each time, knowing that PML has solved the 
low-level EDI syntax issues.

Can you see that by introducing the level of abstraction you don't have to 
"maintain" the EDI message building in every stylesheet mapping every 
vocabulary ... you just maintain it once in your PML->text stylesheet and 
all of your other "step 1" stylesheets such as UBL-Invoice->PML will have 
their own life-cycle.

Page 33 shows that if you implement page 32 using a SAX-based program, some 
XSLT processors will allow you to add the SAX code directly in to the XSLT 
processor as a custom serialization method ... then your stylesheets 
produce EDI syntax directly.

Page 34 shows yet one more step of using XSLT as a front-end to 
applications implementing legacy semantics.

But if your sole objective is to support a single vocabulary (UBL), then 
perhaps adding the level of abstraction is going too far for your 
needs.  Since I am unaware of your requirements, I didn't know which 
approach you were taking ... but wondering if you were taking a flexible 
approach for multiple vocabularies, I was curious what the details were.

Again ... nothing wrong at all with your XSLT stylesheet putting out raw 
text of an EDI message for UBL ... but if you wanted to put the raw text 
logic into its own process, then you can more easily implement 
transformations from vocabularies other than UBL in addition to the one you 
write for UBL.

I hope this helps to paint a picture of some possibilities.

......................... Ken


--
Public courses: Spring 2004 world tour of hands-on XSL instruction
Next: 3-day XSLT/XPath; 2-day XSL-FO - Birmingham, UK June 14,2004

World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal