W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2005

RE: 1.1 WD suggestions on extension attributes/properties

From: Michael Kay <mhk@mhk.me.uk>
Date: Fri, 14 Oct 2005 08:50:02 +0100
To: "'Glen Mazza'" <gmazza@apache.org>, <xsl-editors@w3.org>
Message-ID: <E1EQKKU-0000R3-Op@lisa.w3.org>

XSLT 1.0 had a similar sentence for extension attributes, and you might like
to look at the way we changed it for 2.0. In effect, it now says that an
extension attribute may not change the behavior of the processor to a
non-conformant behavior, but it may change it "to the extent that the
behavior is implementation-defined or implementation-dependent". So if
there's nothing in XSL-FO that says whether the pages in the final document
should be stapled together, you can add an extension attribute asking for
them to be stapled; but if the spec says that they must not be stapled
together, then such an extension would be disallowed.

Michael Kay 

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Glen Mazza
> Sent: 13 October 2005 18: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 Friday, 14 October 2005 07:50:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:24 UTC