Re: Re: Re: Re: Re: order of UNIONs
--- Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> wrote: > Hi Dimitre, > > >> In a way I'm quite looking forward to having node sequences rather > >> than node sets, since it's a frequent trap that beginners fall > >> into, and it will one less thing for David to get mathematical > >> about ;) > > > > You lose one distinct datatype and put two that are quite different > > into one -- I wouldn't call that a step forward. > > The main reason I can see for the introduction of the sequence data > type is to enable us to iterate over, count, sum and get the minima > and maxima of lists of numbers (and other data types) without using > recursive templates. I think that this is a reasonable requirement > that will increase the usability of XSLT. > > To gain this functionality, I guess that other alternatives (aside > from 'sequence') would be: [snip] > Can you think of another design that would work? I wasn't complaining about having 'sequence' -- what I did state was that 'sequence' is 'sequence', and 'node-set' is 'node-set' 'node-set' is an already existing type -- it must continue to exist, even only to ensure compatibility. Any new type can be introduced if appropriate -- this is normal evolution of a language. However, putting foxes and hens together and calling them all hens and treating them just as hens-- this will have such consequences as: 1. The hens, the foxes, or both will suffer (foxes from over-eating). 2. To say that hens are laying eggs will no longer be true. 2. Some hens will have feathers, others -- fur. 3. A new branch of zoology dealing with 'foxhens' will emerge. 4. There would be a lot of feathers in the air. > > What about a template that expects a parameter of type "node-set > > sequence" but gets called with just "sequence"? It doesn't seem > > straightforward and natural to detect such cases and take the > > necessary corrective action. This is what you get when mixing two > > different datatypes together. > > I agree that not being able to detect the type of the value passed to > a parameter is a distinct problem in XSLT. (In most cases, the problem > is one that comes with weak typing, and the implicit coercion to the > required type works OK. The worst, in my opinion, is getting a string > when you expect a node set, because there's no way to detect the fact > and recover gracefully.) > > This case is roughly on a par with the kind of recovery you currently > have to do In XSLT 1.0 you get a run-time error the first time you use a node-set parameter (as node-set), whose actual value was passed as a number. In XSLT 2.0 you could do a lot of processing, wasting a lot of time, until you reach item no. 999 which is a number and not a node -- not even a run-time error will occur to save you from this. Now, in order to prevent such a scenario you will have to include additional code in your templates -- something that you didn't have to do in XSLT 1.0. Programmer productivity will decrease, code will be cluttered and not well maintainable, debugging will be much more complicated, the efficiency of the code itself will be smaller. Cheers, Dimitre Novatchev. __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format