xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Attributes in the XSL-FO Namespace
Date Mon, 04 Oct 2010 17:33:49 GMT
Hey guys,

like so many others, I thought that non-prefixed attributes belong to
the namespace of the element. But I knew there is a difference when
you're programming. Incidentally, I had that exact question during the
XSL training I gave last week. I got away with "it's a bit complicated".
;-) Anyway, I'd like to highlight something:

ODF defines an "fo:" prefix, but not with XSL's namespace:
Prefix: fo
Description: For attributes that are compatible to attributes defined in [XSL].
Namespace: urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0

I wonder why they did that. I assume it's so they can restrict the
subset of allowed FO properties. And indeed, they list every
FO-compatible property in the spec. That makes sense in this case, but
in the case of an FO extension element in a different namespace, not so
much.

OTOH, I would say that using the fo: prefix with XSL's namespace on
non-XSL elements does make sense. As for FO properties in the FO
namespace on FO elements.....I'd say that people should be very strongly
discouraged to do that (due to interoperability), but I don't think it
hurts to be able process them. The only problem is a mismatch with the
XML Namespaces spec which says that font-size="12pt" and
fo:font-size="12pt" are two different attributes and don't clash. But
they do clash when FOP has to process both. One would have to take
precedence. I guess that's part of the problem.

My 0.05 CHF.

On 04.10.2010 18:08:50 Vincent Hennebert 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;
> • put them in the namespace of the original XML application to make
>   their origins explicit or to potentially avoid naming conflicts.
> 
> 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’.
> 
> 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?
> 
> 
> > 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.
> 
> 
> > 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>
> 
> 
> 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




Jeremias Maerki


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


Mime
View raw message