Re: XSL Errata document updated

> The overall impression is that the respective part of the spec
> is still underdeveloped: XPath-like expression syntax is mixed
> to CSS data types, but no tight integration was made. Data type
> definitions in Section 5.11 (copied from CSS) refer to the string
> representation of data tokens as if there were no expressions
> at all: there is no information about mapping of productions
> in 5.9 to property data types.

Even worse : some productions do not match the rest of the document. For 
example, the production for a function does not admit whitespace, while at 
several other places whitespace is admitted before '(' or around the 
arguments.

> Therefore, I am inclined to believe that extra quotes shall be
> excluded in both integers and URIs. "'url(...)'" is a Literal
> whose value is 'url(...)'; it naturally maps to <string> datatype
> that is a different datatype fom <uri-specification>.

Yes, and that is quite natural: one must have a way to quote data for them not 
to be interpreted, as function or as anything else. Saying "'5pt'" is a way 
for an user to pass the <string> made of the characters '5' 'p' 't' and not a 
<length>. It is very nice to have a quoting process that disables 
interpretation, it can always be useful.

> Unless
> a conversion is explicitly permitted by the spec, these two
> should be kept separate.

Yes.

I strongly push forward an in-depth normalization of all the data types, 
functions and syntax stuff, so that :
- productions match data types, functions and operators
- there is a better separation between lexical analysis and syntax analysis
- data types (the things you can communicate with functions like 
from-parent()) are clearly distinguished from the initialization constructs.
- what looks like a function is a function, what looks like an operator is an 
operator, and so on
- perharps we even get rid of the implicit conversions mechanism and 
explicitly list all the allowed argument types for all functions.

Such an in-depth normalization would allow to get rid of the many complex 
explanations that currently exist to explain that <angle>s are in fact 
<string>s and that <percentage>s are in fact <length>s or <number>s (just to 
take two examples).

Let's take an example to illustrate what I mean. A construct that keeps 
puzzling me is the <percentage> "data type".

<percentage> is described as a data type, therefore one could imagine that 
from-parent() could return "50%" for example. But it is specified at several 
places that percentages are evaluated first, so one may think it just as an 
initialization construct, and pass a <length> or <number> through the 
functions. Excepted that in a few properties it seems possible to pass 
percentages (for example background-position-horizontal) according to the 
description of the property. So at the end what is it? A real data type or 
just an initialization construct?

Such a normalization could be for XSL-FO 2.0, as it might introduce tiny 
differences between what was valid and what becomes valid. It would make the 
specification much less subtile and much less subject to interpretation. 
Implementers would benefit from it as it would make engines much simpler and 
robust, and end users would benefit from it as they would retrieve widely 
accepted notions as basic data types.

-- 
- Do you know the four basic nutrition groups?
- Errr... Hamburger, soda, French fries and dessert?

Received on Saturday, 26 October 2002 05:38:18 UTC