[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] Re: Position Paper on List Containers
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]