On 9/6/06, Dan Connolly <connolly@w3.org> wrote: > On Wed, 2006-09-06 at 10:35 +0200, Danny Ayers wrote: > > On 9/5/06, Harry Halpin <hhalpin@ibiblio.org> wrote: > > > Notice I'm intentionally a bit vague about XSLT 1.0 or XSLT 2.0 here. > > > > This bit troubles me a little. Passing an XSLT 2.0 transformation to > > an XSLT 1.0 engine will result in an error, > > Really? Did you get that from a spec or from experience? I'd like > to think there's some forward compatibility. I asked informally on irc: ... danja: so, the question: what happens in general if you pass an XSLT 2.0 transformation to an XSLT 1.0 engine? [6:26pm] ndw: Right. I think that makes sense. [6:26pm] ndw: The XProc stuff that relies on XPath is likely to use 1.0 [6:26pm] ndw: The 1.0 processor performs it in "forwards compatible" mode [6:26pm] ndw: Most things work like you'd expect. Errors that would be fatal in a 1.0 stylesheet aren't and can be caught with an xsl:fallback [6:26pm] ndw: So it's possible, usually, though sometimes it's tricky, to write a stylesheet that will work in either case. [6:26pm] ndw: Probably less work to just write it in 1.0 though, for a grddl transform [6:27pm] danja: but assuming you have an XSLT 2.0 that isn't very XSLT 1.0 considerate - will it just error out in an XSLT 1.0 processor? [6:28pm] ndw: XSLT 1.0 tries not to have very many fatal errors, I think you'll get a lot of defaulted behavior, but ultimately, yes, I think you can make it error out > It certainly seems like a good thing to test in our test suite. Indeed. Cheers, Danny. -- http://dannyayers.com
Received on Wednesday, 6 September 2006 16:40:07 UTC
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3