RE: [xsl] Automatically copying an element's attributes and their values

Subject: RE: [xsl] Automatically copying an element's attributes and their values
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 09 Sep 2003 12:11:25 -0400
At 07:12 PM 9/8/2003, Mike wrote:
I'm interested in people's views on "recoverable errors". In the case of
errors like this that are clearly under the control of the stylesheet
author, should we be making them non-recoverable (fatal) errors? Most of
the new run-time error conditions in XSLT 2.0 are non-recoverable, but
the old 1.0 ones haven't changed much. I think the original reasoning
was that with client-side transformations in particular, it's better to
put anything on the screen rather than a syntax error message. Does
anyone think that's a valid argument?

I do, but I also think that identifies exactly the gap between a transformation language designed only for final transformations into a display format (or onto the screen), which are typically down-conversions (no interpolation of structure, no complex type-based operations, only trivial grouping and sorting), and a transformation language designed for truly arbitrary transformations, including up-conversions and the rest.

As for the question itself, if XSLT 2.0 is truly the latter kind of language, I could live with either option, though if it is a non-recoverable error I'd at least want decent reporting of the problem. Having reasonably useful error messages, however, is something I'm afraid the spec can't mandate, can it? Yet this example (something breaks because xml:space is set to 'preserve') illustrates how obscure problems can be.

Would it be possible for XSLT to work in either mode? Perhaps that's what's implied by the hybrid approach (non-recoverable for new XSLT 2.0 run-time errors, recover 1.0 errors) -- or maybe the hybrid approach is just a muddle, and we really need a switch for "debug" mode or whatever, not a distinction based on having a display transformation technology wrapped inside an arbitrary transformation technology, with blurry boundaries between them?


Michael Kay

XSL-List info and archive:

Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
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:

Current Thread