[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] using position() inside Muenchian groups?


Subject: Re: [xsl] using position() inside Muenchian groups?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 15 Oct 2008 10:31:35 -0400

Eric,

At 09:07 PM 10/14/2008, you wrote:
Yep. That's the database export format that Filemaker produces - rows,
columns, repetitions. No semantic hierarchy. Hating it.

From time to time on this liest, we see the same set of problems mapping Filemaker's XML to arbitrary XML -- as recently as


http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200809/msg00134.html

This suggests to me that someone might make themselves a modest amount of fame (or at least friends) by documenting their FMPXMLRESULT XSLT on line.... :-) The format is rather rough and ready, yes, but not intractable once you get the hang of it.

A two-pass solution -- a first pass to go from FMPXMLRESULT to something cleaner and more descriptive, leaving formatting to a second pass -- might be an especially attractive approach for many of these problems. That first-pass XSLT could be very generic and reusable.
Ah, nice one. Googling the documentation of xsl:number would never have
suggested this solution to me. So, to understand correctly, <xsl:number/>
reports the original position in the source elements, while position()
reports the position in the *selected* sub-set of nodes/elements?

To add to what Ken said, yes, but xsl:number also does more. Actually it generates a number in the form of a formatted string (which when formatted as a conventional Arabic numeral can be cast back to a number) that is sensitive not just to a node's position in the source tree with respect to siblings, but also to ancestors and their siblings. So it supports generating numbers such as "III" or "E.4-iii" as well as "3".


In some processors -- those that have not been optimized or tested sufficiently -- xsl:number can be slow and/or buggy. This (and other reasons such as habit) leads us also to use brute-force methods to determine a node's position in the source tree, such as count(preceding-sibling::*).

Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


Current Thread
Keywords