Re: XSL Errata document updated

Le Friday 25 October 2002 20:54, W. Eliot Kimber a écrit:
> > Oh! OK. Looks like a function... to me? A name, content in braces?
> > I'm more bothered that if you are right, its an exception
> > to 'the family' (xslt, xpath, xsl-fo).
>
> I think it's perfectly consistent with, for example, XPointer which
> requires a scheme indicator around an XPointer term, e.g.,
> href="#xpointer(//foo/bar)", where the syntax has the same syntactic
> form as typical functions, but is not formally called a function, in
> particular, it is not something that can be used in expressions
> generally and it is not defined as returning anything.

Does the fact that it is consistent with other dialects mean that it is a good 
think?

When you implement xsl-fo, you need to write a functions handler anyway. So it 
becomes natural to implement url() as another function that takes a <string> 
as an argument and returns a <uri-specification>. rect() is no function 
either, but it is convenient to use the regular functions mechanism for it 
too.

I have implemented it that way, although I perfectly knew from the 
specification that in fact it is a mere sequence of characters: 'u', 'r', 
'l', etc. I felt safe to do it that way as nobody would see the difference as 
it would parse what is described in the spec exactly as expected. And the 
spec does not mention a single quote before the 'u', 'r', 'l' sequence ;-).

If in XSL-FO 2.0 things could become more consistent, and if url() and rect() 
could become regular functions, and in general if things could be made less 
subtile and more orthogonal, then the life of implementers would really 
become simpler. And perharps even users' life too.

Just my two eurocents.

-- 
- Linux produces remarkedly less hot air than Windows: under
Windows, the processor gets hot after just a few minutes...
- Yes, but it never stays on long enough to burn out!

Received on Friday, 25 October 2002 17:43:42 UTC