Re: [ubl-lcsc] Re: Position Paper on List Containers

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

At 2003-09-01 18:59 -0700, jon.bosak@sun.com wrote:
>Tim,
>...
>I have to admit that you guys have raised some
>pretty serious concerns.  I was surprised to read this:
>
>    The UBL Form Presentation group hold no strong opinion on the
>    value of such structures to their processing requirements.
>
>That's not at all what I would have expected intuitively, and I
>think it somewhat weakens the point I was trying to make about the
>user interface.

Hold the phone a bit here ... I'm unaware of where Tim's comment regarding 
FPSC is substantiated (though I may have missed something somewhere, so I 
apologize if that is the case).

In Montréal I did comment that containers are "a good thing" in the 
processing of siblings: specifically, handling a set of repeated siblings 
amongst a collection of dissimilar siblings is more awkward than handing a 
collection of like siblings as what happens when they are containerized.

It is a personal practice of my own document modeling to containerize a 
collection of like-named siblings to keep them away from siblings of 
differing names.

Consider the typical native XSLT processing when a user uses:

    <xsl:apply-templates/>

... and the built-in template for elements that also utilizes this.

This instruction takes advantage of the inherent structured nature of XML 
instances, processing all of the child nodes between the start and end tags 
of the current element.

Consider the example below where containerized processing of address lines 
produces the correct numbering 1,2,3 and 4, while the non-containerized 
processing produces the incorrect numbering 2,3,4 and 5, using the same 
stylesheet that is taking advantage of the inherent nested processing of XML.

Certainly I can change the stylesheet to explicitly process non-address 
lines and then address lines and produce the correct answer with the 
non-containerized input, but that isn't my point.  My point is that 
containerization better supports the inherent processing of sibling 
elements of like names.

Intuitively (but not yet empirically) I believe it will be easier to 
support in stylesheets a lot of what I anticipate we will see in end-user 
customization of UBL document models.  That we don't know what our users 
will be doing with our document models should be reason enough to build 
structures that can be more easily processed not knowing what our users 
might do.  (I think I said that right!).

Having worked with OmniMark and Python/SAX and Python/DOM I think I can 
extrapolate parallel benefits in *all* downstream processing if repeated 
siblings are containerized.

I hope this helps the discussion *from the perspective of downstream 
processing* (including stylesheets) ... which is only one perspective of 
the many that would need to be considered ... I don't want to imply this is 
overarching.

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


T:\ftemp>type proc.xsl
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
                 version="1.0">

<xsl:output method="text"/>

<xsl:strip-space elements="info addressLines"/>

<xsl:template match="name">
   Name: <xsl:apply-templates/>
</xsl:template>

<xsl:template match="address">
   Address: <xsl:value-of select="position()"/>: <xsl:apply-templates/>
</xsl:template>

</xsl:stylesheet>
T:\ftemp>type cont.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<info>
   <name>G. Ken Holman</name>
   <addressLines>
     <address>P.O. Box 266</address>
     <address>Kars, Ontario</address>
     <address>Canada</address>
     <address>K0A-2E0</address>
   </addressLines>
</info>

T:\ftemp>saxon cont.xml proc.xsl

   Name: G. Ken Holman
   Address: 1: P.O. Box 266
   Address: 2: Kars, Ontario
   Address: 3: Canada
   Address: 4: K0A-2E0
T:\ftemp>type nocont.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<info>
   <name>G. Ken Holman</name>
   <address>P.O. Box 266</address>
   <address>Kars, Ontario</address>
   <address>Canada</address>
   <address>K0A-2E0</address>
</info>

T:\ftemp>saxon nocont.xml proc.xsl

   Name: G. Ken Holman
   Address: 2: P.O. Box 266
   Address: 3: Kars, Ontario
   Address: 4: Canada
   Address: 5: K0A-2E0
T:\ftemp>


--
Next public European delivery:  3-day XSLT/2-day XSL-FO 2003-09-22
Instructor-led on-site corporate, government & user group training
for XSLT and XSL-FO world-wide:  please contact us for the details

G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                       Definitive XSLT and XPath
ISBN 0-13-140374-5                               Definitive XSL-FO
ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:     http://XMLGuild.info
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc