Hi Edward,
At 03:37 PM 4/20/2005, you wrote:
From what I understood from the responses following last week's proposed
solution is that it wouldn't work under XSL ver. 1. I just tried it
again, and the error I get is "Reference to variable or parameter 'mixed'
must evaluate to a node list."
There were several solutions last week, IIRC; this was only one of them.
In any case this particular solution does require an extension function....
Can you explain what this code is supposed to be doing? I did not
understand the more complex xpath expressions you used or the
"mode='unmix'" attrib.
(Who provided that code? Can't remember now. :-< )
Grouping is not something I am very familiar with because most of what I
am working on has been straight display of a document text and has not
involved much in the way this kind of manipulation. I read what I could
find about grouping following your post but many of the explantions and
examples I could find do not use it in the way you seemed to have.
Yes, "grouping" comes to be shorthand (or synecdoche, if you like) for a
class of problems including things you wouldn't ordinarily think of as
grouping, but which are grouping nonetheless, such as wrapping a set of
contiguous nodes in an element ... what we have in this case.
I am still in disbelief that something as common as a blockquote was not
accounted for when XSL was designed. I mean they knew XML would encourage
get people to properly structure the data (as this is part of the point)
and they knew that HTML/XHTML did not recognize block level elements
inside one another. And yet, they crerated a transformation standard with
no simple way to change one into the other. The result it seems is a
"powerful" transformation standard that cannot easily transform something
as simple as a high school term paper or a newspaper article.
It wasn't the "blockquote" they didn't consider; it was this entire class
of transformations (grouping based on element sequence and proximity). But
what you don't know is that XSLT 1.0 was intended to be lightweight and to
serve, primarily, the requirements of transforming into XSL-FO. (The intent
of its developers has shifted somewhat in the time since, given how the
markets have evolved.) XHTML didn't exist, and no one was really validating
their HTML back then. (Are they now? ;-)
XSL-FO lets you nest fo:block elements to your heart's content -- with that
kind of target this is actually an edge case after all.
As even XHTML allows you to nest divs ... you might consider taking that
approach.
I will continue to try to understand the more complex parts of XSl (that
until now it seems I haven't had to use) and try to decifer your solution.
While I understand that maybe the solution you offered will work and that
I am just not doing something right, but it really souldn't be this
complicated should it?
No it shouldn't ... yet keeping my inbox free of spam shouldn't be so
complicated either, should it? Sometimes a technology springs out of the
form that its original designers thought it would take. Nor is this always bad.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--