Re: Fixing <b>

Lea Allison wrote:
> Very helpful Mike.

tammy@xxxxxxxx wrote:
> Great thanks!  I should have made it clear that I had no control about the
> crappy data I was being given.  I work in an environment where XSLT isn't
> respected, because it's not well understood, IMO.  Now I'm being asked if XSLT
> can deal with THIS situation. 
> 
> I appreciate your insight! It's extremely helpful.

There was some discussion recently on this topic, on xml-dev. It was said that
people who ask questions here often just want immediate solutions, no matter
how poor the code, not to be taught how to fish. "Just tell me what to type to
make it work; your lectures are boring!" was the example one person gave. But
as the other responses besides my own (from Michael Kay and naha@xxxxxxxxxx)
indicate, there is not much sympathy for this sentiment around here ... at
least not among those of us who value writing good code to work with good
data, and who don't want to be caught telling people how to write bad code to
work with bad data.

What I'm saying is that everyone is hesitant to tell you how to make it work
in XSLT because you're banging on a nail with a wrench. You either need a
hammer instead of a wrench, or a nut & bolt instead of a nail. And I wasn't
exagerrating, it really is a FAQ -- check http://www.dpawson.co.uk/. The
standard response really is to either goad the people responsible for the
crappy data into fixing it, or to not use XSLT, because trying to work with
this kind of data in XSLT, in the way that you want to do it, while not
impossible, requires using a much despised feature (disable-output-escaping)
that undermines the language's principle of being something meant to work with
trees, rather than being a general text processing tool.

If I were you, and if it's easy to spot the ugly data (like if it's always in
a 'p' element), I would fix it using, say, a SAX filter, so I could apply my
XSLT to something a bit easier to deal with. If the transformation is trivial,
I might skip using XSLT altogether.

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/

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