OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Ten new XQuery, XSLT 2.0 and XPath 2.0 Working

[ Lists Home | Date Index | Thread Index ]

On Sun, May 11, 2003 at 04:23:08PM -0400, AndrewWatt2000@aol.com 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@w3.org, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS