Re: XSL Errata document updated

Is this an offer to propose the necessary
amendments Eric?

regards DaveP


At 10:38 26/10/2002, Éric Bischoff wrote:

>> 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:52:49 UTC