[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Eric,
At 09:07 PM 10/14/2008, you wrote:
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.
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::*).
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] using position() inside M, G. Ken Holman | Thread | Re: [xsl] using position() inside M, Eric Scheid |
Re: [xsl] EXSLT and XSLT 2.0, Colin Paul Adams | Date | Re: [xsl] using position() inside M, Eric Scheid |
Month |