[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working

• To: xml-dev@l...
• Subject: Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
• From: Liam Quin <liam@w...>
• Date: Mon, 12 May 2003 00:23:48 -0400
• In-reply-to: <10d.24379619.2bf00b2c@a...>; from AndrewWatt2000@a... on Sun, May 11, 2003 at 04:23:08PM -0400
• References: <10d.24379619.2bf00b2c@a...>
• User-agent: Mutt/1.2i

On Sun, May 11, 2003 at 04:23:08PM -0400, AndrewWatt2000@a... wrote:
[...]

> Is it possible to feed into the W3C system the suggestion that Use Cases 
> should be a routine early step for all proposed specs?

It's hard to balance beaurocracy and usefulness. I think we should
encourage use cases informally, and require (as we do) requirements
documents.  Use case methodology is one of many.

The role of the W3C Team, though, and the staff contact, means that
we do have a mechanism for encouraging such things -- we have a staff
(mostly technical) of approx 70 people.  But I don't want us to make
Working Groups have to produce more documents in all cases, even if
it doesn't really make sense.

> I don't want to over emphasise the difficulties but there are little issues 
> like this, which was brought up on XSL-List today:
> 
> concat("some string", position(), ".html")
> 
> which needs an explicit cast on position() to avoid a type error.
> No big deal 

The useful thing here is that this can be detected easily at "compile time".
Although your example is clearly a bug, consider the common error,
    concat(page, position(), ".html")
instead of
    concat("page", position(), ".html")

which does the "wrong thing" silently in XSLT 1, and is now an error
(assuming there's no conveniently located page element of course!)

> If the upgrade pathway from XSLT 1.0 / XSLT 2.0 for existing XSLT users is 
> smooth, I find it difficult to see any reason for staying with XSLT 1.0. The 
> extra functionality in XSLT 2.0 is very attractive.

There's no reason for people to change, if wht they have is working. On
the other hand, I routinely run XSLT stylesheets through at least two
implementations (usually saxon and xsltproc) to maximise the chances of
finding errors.  Better error checking, and *especially* more static
analysis ("compile time" errors, if you like), will be wonderful.

Especially errors in parts of my style sheet that were not reached
with my test data.

And if the result is also that XSLT transformations happen more
quickly, more efficiently, especially on large amounts of data, that's
a pretty good win.

Liam

-- 
Liam Quin, W3C XML Activity Lead, liam@w..., http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

• Follow-Ups:
  • Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
    • From: Jeni Tennison <jeni@j...>

• References:
  • Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
    • From: AndrewWatt2000@a...

• Prev by Date: Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
• Next by Date: Can xpath replace DOM/SAX?
• Previous by thread: Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
• Next by thread: Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
• Index(es):
  • Date
  • Thread