Thanks for taking the time to write that email. Greatly appreciate it.
To answer your question about moving to XSLT 2.0, unfortunately that is not
an option. So I'll have to find a solution to merging the two cells and
formatting the date using whatever functionality is available in 1.0.
So far I'm still in the dark as to how I can merge the cells.
----- Original Message -----
From: "Wendell Piez" <wapiez(_at_)mulberrytech(_dot_)com>
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Sent: Friday, March 27, 2009 1:17 PM
Subject: Re: [xsl] Need help combing two elements
Fatbob,
At 09:00 AM 3/27/2009, you wrote:
I worded it incorrectly, but yes I don't want to change the data itself,
simply how it is displayed.
Don't worry, I'm just quibbling. (And maybe helping to reinforce
correct impressions.)
The data is very predictable. It will always be as I've shown above, so I
have no worries about that. I'm not sure what you mean by "edge cases".
I'm
very new to XSL, as demonstrated by my use of incorrect terminology.
In the parallel thread with Alan, we are talking about templates
without using them much.
The reason templates are relevant is that they are the way XSLT
manages complexity.
Managing complexity is important and relevant because XSLT is
designed to deal with transformation problems where there are
constraints over the input (commonly enforced with a schema to which
the input must be valid), but those constraints are fairly loose, and
may not govern the exact number or arrangement of elements, only
their names, the names (and sometimes values) of their attributes,
and their content models -- what elements they may (or may not)
contain and in what general orders and combinations.
Think of processing an XHTML document as input, where you might have
divs containing paragraphs, lists, tables, and paragraphs and list
items may contain inline markup and anchors and what not, all in a
big mishmash, and recursively when tables or divs or lists contain
tables or divs or lists or whatever else, and you get the idea.
Or generalize from there to a more properly "descriptive" document
tag set such as Docbook, TEI, NLM Journal, or DITA (it shouldn't be
too hard to find examples of any of these on line), and you'll get an
even better idea.
XSLT is perfectly capable of handling more regular inputs, such as
database or structured data dumps, because this is generally an
easier set of problems. (Making wooden boxes is not hard when you
have power tools designed for making furniture.)
To get back to your question, "edge cases" is a way of describing
possible inputs, which you are required to handle, but which are not
perfectly normal or regular.
Of course, whether you have edge cases, of what sort they are
(elements in a different order, elements with or without particular
children or attributes, elements missing or duplicated, etc. etc.),
and whether they are really "edge cases" or in fact perfectly normal,
differs from one problem to another.
The first problem that needs to be considered when designing a
transformation is what kind of boundaries can be drawn around the
range of inputs. While these boundaries are probably obvious to you,
since you are looking at the whole problem, it's a live question to
any of us, since we see only the tiny piece of it you've shown.
I hope I don't sound like I'm lecturing. I'm actually just trying to
draw lines around the fascinating problem of drawing lines around
problems.
But in general, the casting of values such as "Mar 23, 2006" to
"2006-05-03" is going to be more work than the combining of values
from two (or several) elements into one.
Yes, I thought formatting dates would be much easier, but it does appear
to
be quite tricky.
It will be much easier in XSLT 2.0 if you have the option of using that.
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>
--~--
--~------------------------------------------------------------------
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>
--~--