Re: [xsl] A Question **TO** XSLT Newbies

Subject: Re: [xsl] A Question **TO** XSLT Newbies
From: "James J. Ramsey" <jjramsey_6x9eq42@xxxxxxxxx>
Date: Mon, 21 Apr 2003 15:46:21 -0700 (PDT)
--- Andrew Watt <andrew@xxxxxxxxxxxxxx> wrote:
> At 07:28 21/04/2003 -0700, you wrote:
> >I'd suggest separating point 3 into two subpoints:
> >
> >3a. *How* will I get the data?
> >3b. How will I channel that data into the output?
> >
> >In my short experience with XSLT, point 3a was the
> >difficult part. I knew what data I wanted, but
> didn't
> >know at the time how to get to it. That's
> especially a
> >difficulty if one is not in control of the format
> of
> >the data source.
> 
> James,
> 
> An interesting suggestion. Thanks.
> 
> Can you dissect out whether your problem was in
> mastering XPath 
> syntax/concepts or how XPath fits with the flow
> among XSLT templates?
> 
> To put it explicitly, is 3a having a problem with
> XPath? Primarily? Or not 
> as simple as that?

Definitely *not* as simple as that. Frankly, I
wouldn't blame XPath so much as I would the problems
introduced by the DTD I was working with. Basically, I
had to figure out a way to capture certain elements
that were between other elements. The details of the
problem are in the thread "How to render TEI <div*>s
with chapter-like pagination?" 

However, some of the problems I had to deal with were
due to subtleties in XSLT and XPath. For example, it
took me a while to figure out *why*
preceding-sibling::foo[1]|preceding-sibling::bar[1] is
different from
(preceding-sibling::foo|preceding-sibling::bar)[last()].
This is especially important when trying to figure out
appropriate arguments to functions, like
generate-id(), that take the first member of the node
set argument as input. It also would have been nice if
xsl:key were explicitly explained -- and illustrated
-- as setting up a form of look-up table. (Of course,
xsl:key might very well have been explained that way
in other places. My access to XSLT documentation is
somewhat limited.) I have also noticed that in the
documentation I have seen that the position() function
is used in examples as if its output were always
obvious, when in fact it can produce very puzzling
results unless its context is carefully controlled or
understood. Examples of the usage of xsl:number seem
to be especially prone to this problem. The main catch
I see with XPath is that it has subtleties that make
sense once one understands *exactly* what the syntax
is specifying, but are seemingly random if one's
understanding is off by a little bit.


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread