W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2005

[Bug 1264] New: [XSLT] Reconsider XTDE1480

From: <bugzilla@wiggum.w3.org>
Date: Thu, 21 Apr 2005 15:46:32 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DOdsu-0002Ih-35@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1264

           Summary: [XSLT] Reconsider XTDE1480
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: Norman.Walsh@Sun.COM
         QAContact: public-qt-comments@w3.org


I'm having some second thoughts about this error:

  [ERR XTDE1480] It is a non-recoverable dynamic error to evaluate the
  xsl:result-document instruction in temporary output state.

The ability to easily access result trees is going to make it very
tempting to deal with some sorts of customizations by simply putting
all the "normal" results in a variable and then transforming that
variable. (Think next-match or apply-imports.)

But XTDE1480 means that if any "normal" result constructs an output
document along the way (as the DocBook stylesheets can for "long
descriptions" of figures and tables per the WAI guidelines),
then that technique is going to fail. In fact, for the current DocBook
stylesheets it's even worse than that since the body of a figure or table is
passed as a parameter right now and so fails even in the simplest case.

I appreciate that result documents created in a variable or other
temporary context might be unpredictable but I would much prefer that
unpredictability to what we have today.

The workaround (and I will have to workaround this problem) will
be to put all the result-document content in the primary result
tree (wrapped in <magic:wraper> elements or something) and then post
process the result to write them out. In other words, it will force
me to always process every tree twice. That's going to be potentially
expensive.
Received on Thursday, 21 April 2005 15:46:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:37 GMT