xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Adams <gl...@skynav.com>
Subject Re: Attributes in the XSL-FO Namespace
Date Tue, 05 Oct 2010 02:38:29 GMT

On Tue, Oct 5, 2010 at 12:08 AM, Vincent Hennebert <vhennebert@gmail.com>wrote:

> Glenn, Simon,
> Thanks for your answers. So, IIUC the designer of an XML application is
> free to re-use attributes from other XML applications, and has two
> possibilities:
> • put them in the null namespace and document them as originating from
>  this or this XML application;

[GA] To be more clear,

   1. if document type D1 defines an attribute in some global namespace,
   then one can always adopt the use of that attribute (in its defined global
   namespace) for use in another document type D2;
   2. if document type D1 defines an attribute in a per-element namespace on
   some element type, then one can reuse the name and even the definition of
   that attribute on an element type in D2, but it is not the same attribute,
   because the per-element namespace in which it is defined in D1 is not the
   same per-element space in which it is defined in D2;

By the way, it is better to not use the term "null" namespace, but to think
of it is a "per-element (type) namespace", since there are as many such
namespaces as there are elements on which such attributes are defined, and
not just one global "null" namespace.

• put them in the namespace of the original XML application to make
>  their origins explicit or to potentially avoid naming conflicts.

This is what I describe in point 1 above. However, when you say "put them in
the namespace of the original XML application" what I think you mean is
either (1) locally redefine them in that same original namespace with all
else being equal for the definition or (2) refer indirectly to their source
(original) specification schema, e.g., by using the XSD include mechanism.

> That said:
> On 04/10/10 12:21, Simon Pepping wrote:
> <snip/>
> > <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.
> That sentence is, I believe, irrelevant, and anyway inconsistent. That
> sentence says that ‘if an attribute not in the XSL-FO namespace is
> accepted on an XSL-FO element, then that attribute is in a non-null
> namespace.’ It doesn’t say: ‘if an attribute is in a non-null namespace,
> then that namespace must not be the XSL-FO namespace’.

Actually, I believe Simon is correct. I believe he is quoting from the XSL
spec itself, which here is saying the following:

   - if you want to use a non-standard, extension attribute on an XSL-FO
   defined element, then you must put it in some (non-null) namespace, and,
   further, you must not put it in the XSL-FO namespace;

So, e.g.,

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" *
<fo:block foo:bar="..." />         <!-- ok - foo:bar is in another
non-XSL-FO NS -->
<fo:block foobar="..."/>           <!-- not ok - foobar is not in another
non-XSL-FO NS -->
<foo:baz foobar="..."/>            <!-- ok - presumes foobar is defined on
foo:baz -->
<foo:baz fo:font-family="..."/>    <!-- not ok - XSL-FO does not define
font-family in XSL-FO NS -->
<foo:baz foo:bar="..."/>           <!-- ok - presumes foo:bar is defined in
foo NS -->

Note also, that the use of any prefix in an XML document other than the
'xml' prefix is non-normative. That is, any prefix (including) none may be
used in a namespace declared document provided the appropriate xmlns
attributes are present; i.e., there is nothing normative about the use of
the 'fo' prefix in an XSL-FO document. The following documents are
equivalent and valid:

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"/>
<xx:root xmlns:xx="http://www.w3.org/1999/XSL/Format"/>
<root xmlns="http://www.w3.org/1999/XSL/Format"/>

> Now, that sentence is inconsistent because it mentions ‘attributes from
> the XSL-FO namespace’, and strictly speaking there are no such
> attributes, since the recommendation defines all of them as being in the
> null namespace.
> So, it may well be that technically speaking, according to the XML
> Namespaces recommendation, non-prefixed attributes belong to the null
> namespace; but everyone seems to implicitly consider them as belonging
> to the namespace of the element on which they are defined. Including
> other W3C recommendations. In light of that, why not accepting
> explicitly prefixed attributes, then?

First, anyone who "implicitly considers them as belonging to the namespace
of the element on which they are defined" is wrong. Just because people
make that mistake doesn't mean those who know should copy it.

You say that "other W3C recommendations" make this mistake? Could you
point out such an error please?

> 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.
> Well, nothing prevents me from prefixing all the attributes of my XSL-FO
> file with the XSL-FO namespace, without otherwise introducing any
> extension. Independently of the definition of any extension, the
> question is whether we are happy to accept construct of the kind
> ‘<fo:block fo:font-family’ or not.
> [Glenn:]
> > if one wants to use XSL-FO attributes on non-XSL-FO element types,
> > then
> > simply use them (without a namespace prefix), however, in that case they
> > effectively reside in the per-element namespace of the element that uses
> > them; i.e.,
> >
> > <ext:foo xmlns:ext="..." font-family="..."/>
> >
> > is fine, though here font-family lives in the per-element namespace of
> > ext:foo;
> No, they are in the null namespace.

If you go back to the original publication of XML Namespaces, at


You will see that what I refer to as "per-element namespace" is called the
"per-element-type partition", so I am not inventing this, but perhaps I
should not refer to it as a "namespace" as such, since it leads to such
confusion as "null namespace", etc.

In the most recent edition of the XML
Namespaces<http://www.w3.org/TR/xml-names/>specification, Section 6.2
writes (emphasis added):

Default namespace declarations do not apply directly to attribute names; *the
interpretation of unprefixed attributes is determined by the element on
which they appear*.

This essentially paraphrases the notion of a "per-element" scoping
mechanism, so I believe I'm consistent on this point.

Actually, there is no such thing as "the null namespace" (See Myth #7
in Namespace
Myths Exploded <http://www.xml.com/lpt/a/395>). Neither the first nor the
current XML Namespaces spec defines or uses the term "null namespace".

Names of elements and attributes that are not defined in a namespace simply
have no namespace (whatsoever), although some, like me, tend to refer to
non-namespace defined attributes as belonging to a "per-element namespace".
We do that, because, operationally speaking, the element on which they are
defined is the scope for uniqueness of the attribute name; i.e., attribute
foo on element bar is a different attribute than attribute foo on element
baz. On the other hand, attribute xxx:foo on bar is the same attribute as
attribute xxx:foo on element baz, but this presumes an existing definition
of xxx:foo in some identified namespace, where xxx binds to a non-empty URI.

The term "null" namespace comes from implementation usage, wherein a
namespace value associated with a name is specified as the null value, but
that doesn't mean there is a normative entity known as the "null namespace".

> > why do you say "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’"?
> To make it clear that that attribute is being re-used from the XSL-FO
> recommendation. But following clarifications from Simon and you,
> I withdraw that.
> > <ext:foo xmlns:ext="..." fo:font-family="..."/>
> >
> > is not fine (FO doesn't define font-family in a global namespace);
> >
> > this quirkiness in XMLNS comes from historical artifacts to accommodate
> > backwards compatibility with pre-namespace validators;
> <rant>
> That’s well and good but that introduces inconsistencies that are now
> set in stone forever (ok, for the lifetime of XML). And hassles for
> thousands (millions? ;-) ) of XML users and developers.
> </rant>

You might find the following interesting reading, the first from James Clark
who served as primary technical editor/author for XML 1.0. The second covers
a number of "myths" about XMLNS usage, see #4 and #7 in particular.

James Clark's Random

Namespace Myths Exploded <http://www.xml.com/lpt/a/395>

> Thanks,
> Vincent
> > 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
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message