Re: 1.1 WD suggestions on extension attributes/properties

Hi,

1.) I would be in favour of allowing extension properties to modify
the formatting behaviour, so long as they degrade properly. This means
that a processor should be allowed to ignore them and fall back on
standard formatting behaviour.

2.) It would be more robust if non-inheritable properties would only
be allowed on the formatting objects they are defined on. This could
break existing XSL-FO documents of course.

Regards,

Werner.

Glen Mazza wrote:
> 
> Hello Editors,
> 
> A question just came in on the FOP-User mailing list that appears to 
> raise two issues in the 1.1 WD (text also in 1.0) regarding the wording 
> in "2.2 XSL Namespace" section[1]:
> 
> 1.)  Quote: "An element from the XSL namespace may have any attribute 
> not from the XSL namespace, provided that the expanded-name of the 
> attribute has a non-null namespace URI. The --->presence of such 
> attributes must not change the behavior of XSL elements<--- and 
> functions defined in this document.":
> 
> The arrowed portion above indicates that implementors may not create 
> extension properties that provide any change to the functionality and/or 
> appearance of the XSL formatting objects (that would otherwise be 
> ignored by another implementation that doesn't understand the extension 
> property).  If I am reading this correctly, extension properties may 
> then only have semantic value for extension (i.e., non-XSL) formatting 
> objects.
> 
> But I'm unsure of the benefit of that rule.  There doesn't appear to be 
>  much value in allowing an extension attribute to be attached to XSL 
> FO's if they may not alter the processing of that FO's.  Also, it is the 
> various implementators' work on extension attributes on already defined 
> XSL FO's that help these extensions to be incorporated as official XSL 
> properties in a future release of the recommendation.  Further, these 
> extension attributes could still be ignored with no effect on the 
> standard FO functionality for another implementation that would not 
> understand the extension attribute.
> 
> I guess my recommendation would be to remove the sentence containing the 
> arrows above.
> 
> 2.)  Quote:  "It is an error for an element from the XSL namespace to 
> have attributes with expanded-names that have null namespace URIs (i.e., 
> attributes with unprefixed names) other than attributes -->defined for 
> the element<-- in this document."
> 
> The arrowed portion appears to contradict the rule that "Every 
> formatting property may be specified on every formatting object." ([2], 
> first sentence of chapter 5.)  For example, I can place "starting-state" 
> (null namespace URI) on fo:block, even though this property is not 
> "defined for the element in this document."
> 
> If I'm correct here, my recommendation would be to remove "for the 
> element" at the very end of the quote above.
> 
> Thanks,
> Glen
> 
> [1] http://www.w3.org/TR/xsl11/#xsl-namespace
> [2] http://www.w3.org/TR/xsl11/#refinement
> 
> 
> 

-- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 14 October 2005 08:33:13 UTC