[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: using position() inside Muenchian groups?

Subject: Re: using position() inside Muenchian groups?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 15 Oct 2008 10:31:35 -0400
Re:  using position() inside Muenchian groups?
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.