[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Problem selecting following::code
> Shorter, concise questions tend to get more answers as the person > answering the question doesn't have to invest too much time in reading > and understanding the problem. With the usual addenum of simple as possible but no simplier. Error messages should be included verbatim, problems should be described fully, and it's always nice to have a represenative version of the XML input and output expect. Avoid statements like: "It didn't work.", "Nothing happened.", "I think my processor is broken, this XSLT should work, correct?" (without giving input XML). Instead use statements like "I tried running my script but it produced no output except for root element. Here is input XML .. and I'd like to output it like ... and here is my XSLT that doesn't work." Trying simplified versions of problems before posting has always been known to lead to solutions ;). I tend to prefer a problem statement at top and then any additional info below, but that's just me. I think I've heard others say they like the reverse. Not saying that the Original Poster committed any of these sins, but while we're doling out advice on postings I figured I'd put my own 2-cents in. Jon Gorman
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|