Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Mon, 4 Oct 2010 13:21:49 +0200
From: Simon Pepping <spepping@leverkruid.eu>
To: general@xmlgraphics.apache.org
Subject: Re: Attributes in the XSL-FO Namespace
Message-ID: <20101004112149.GA3757@leverkruid.eu>
Mail-Followup-To: general@xmlgraphics.apache.org
References: <4CA610F9.7050501@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CA610F9.7050501@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

There are a few specs that define attributes in their namespace,
e.g. xml:lang, xlink attributes. Those attributes are designed to be
used in any document in any namespace, so their name must be uniquely
defined.

The XSLT spec defines something like you describe, see XSLT2, section
3.5 Standard Attributes: Attributes that are defined in the spec,
should be in the no-name namespace on elements in the xslt namespace,
but when they are used on literal result elements they should be in
the xslt namespace. This is relevant to attributes whose setting is
inherited by descendant elements, e.g. xsl:default-collation.

Note that the spec also says 'It is recommended that all these
attributes should also be permitted on extension instructions, but
this is at the discretion of the implementer of each extension
instruction.'

The XSL 1.1 spec only briefly mentions extension elements in section
2.2 XSL Namespace, and says nothing about the use of attributes
defined in the spec.

It is imaginable that an implementer of an extension element specifies
the use of some attributes defined in the XSL 1.1 spec with exactly
the same meaning. This is especially useful for attributes whose
setting is inherited by descendant elements. It is imaginable that the
implementer specifies that such attributes should be used with the
XSL namespace, to clarify their meaning as defined in the XSL
spec. But note that such an implementer is free to specify anything.

<fo:block fo:font-family="Helvetica"> is absolutely not acceptable:
'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.' Your patch should ensure that.

At the moment FOP does not define extension elements. A patch to
accept the XSL namespace on attributes becomes only relevant when you
also introduce such an element.

Simon

On Fri, Oct 01, 2010 at 05:48:57PM +0100, Vincent Hennebert wrote:
> Hi,
> 
> Posting here as this may be of interest to Batik devs, since the same
> issue equally applies to SVG.
> 
> A colleague of mine recently stumbled upon an interesting issue: he was
> mixing elements in the XSL-FO namespace with custom extension elements
> in another namespace, that were re-using some of the existing XSL-FO
> properties. Something like this:
>   <fo:block font-family="Times">
>     Lorem ipsum dolor <ext:my-extension-element fo:background-color="blue">...
>   </fo:block>
> 
> He was using XSLT attribute-sets that could be applied to FO elements as
> well as extension elements, and found things like the following among
> the result:
>   <fo:block fo:font-family="Helvetica">
>     Blah...
>   </fo:block>
> 
> Which makes me wonder: is there anything wrong with that? According to
> the XML Namespaces Recommendation [1]: ???The namespace name for an
> unprefixed attribute name always has no value???. So in case 1 above, the
> ???font-family??? attribute has no namespace. But if I want to re-use it on
> some extension element, I obviously have to specify that it comes from
> XSL-FO, so will prefix it with ???fo???. In which case it will be in the
> XSL-FO namespace.
> 
> But then why wouldn???t I be able to prefix it when I specify it on an FO
> element, like in case 2 above?
> 
> It seems to me that it would have been more logical to state, in the XML
> Namespaces recommendation, that the namespace name for an unprefixed
> attribute name is the same as the element on which it is defined. But we
> obviously cannot change the recommendation. So the solution probably is
> for FOP to treat attributes in the XSL-FO namespace the same way as
> non-prefixed attributes. This is simple to do and can be found in the
> attached patch.
> 
> My questions are:
> ??? does anyone have an idea of why the XML Namespaces recommendation was
>   written this way?
> ??? what do you think of the attached patch?
> ??? any general thoughts on this?
> 
> [1] http://www.w3.org/TR/xml-names/#defaulting

-- 
Simon Pepping
home page: http://www.leverkruid.eu

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org