W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Re: Proposed component list

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 01 Feb 2007 07:32:26 -0800
To: public-xml-processing-model-wg@w3.org
Message-ID: <87lkjhyjud.fsf@nwalsh.com>
/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| On 1/31/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
|> I think we want an XSLT1 component that processes XSLT 2.0 stylesheets
|> in forwards compatibility mode and an XSLT2 component that processes
|> XML 1.0 stylesheets in backwards compatibility mode.
|>
|> Defining a single component that does both puts a significant burden
|> on implementors and users, IMHO.
|
| On which way would this make it easier for implementors? I can see
| that with 2 distinct components implementors won't need write code
| that looks at the version attribute to decide which XSLT engine to
| use, but I wouldn't consider this a significant burden.
|
| What about users: in which way would two components make this simpler
| for users? Isn't this creating unnecessary burden by asking them to
| specify the version both in the stylesheet and in the component name?

XSLT has well defined semantics for running a 1.0 stylesheet through a
2.0 processor and vice versa. It simply isn't the case that looking at
the version attribute on the root element of the initial stylesheet
element tells you what processor to run.

Besides which, there's the extra complication about whether sequences
are allowed, etc.

I don't see any benefit in adding a notion of chameleon components to
our language.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Thursday, 1 February 2007 15:33:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:49 GMT