RE: 1.1 WD suggestions on extension attributes/properties

Regarding your item 1, the current wording is
meant to imply that extension properties may
only change the behavior of an FO in ways that 
are beyond what the spec says for a particular 
FO.  Some examples of permitted extensions might
be like specifying a hyphenation dictionary or 
hyphenation exception, specifying a whitespace
distribution algorithm, etc.

While the XSL FO SG was somewhat divided on
the issue, and we certainly do appreciate the
viewpoint you espouse, on the whole we have
decided to stick with the more restrictive 
intension currently in the spec.  We feel that 
allowing for extensions that substantially change 
the already defined semantics for a given FO will 
cause too many implementation issues.

We are planning to clarify the spec be including 
something like:

 This means that an extension attribute must not 
 change the processing of any FO in such a way that
 the constraints specified by XSL on that FO are
 no longer satisfied.

On your item 2, we agree.  We will make the
change you suggest.

Paul Grosso
for the XSL FO SG 

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Glen Mazza
> Sent: Thursday, 2005 October 13 12:06
> To: xsl-editors@w3.org
> Subject: 1.1 WD suggestions on extension attributes/properties
> 
> 
> 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
> 
>

Received on Wednesday, 18 January 2006 19:57:33 UTC