xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vhenneb...@gmail.com>
Subject Re: Attributes in the XSL-FO Namespace
Date Tue, 05 Oct 2010 15:53:28 GMT
Hi Glenn,

Thanks for your additional precisions. I realise that I didn’t have it
quite right yet in my previous message.

Inline:

On 05/10/10 03:38, Glenn Adams wrote:
> Inline.
> 
> 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.

Ok, that’s actually what I meant. “Per-element namespace” is indeed
more accurate.


> • 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.

Well, that was not what I meant, but I now withdraw that sentence and go
for the more correct point 2 you wrote above.

We are actually dealing with two layers here, the syntactical one and
the semantic one. From a purely syntactical point of view:
• an attribute without a prefix is in no namespace;
• IIC, it’s perfectly legal to define a new element belonging to some
  extension namespace, that will accept a ‘font-family’ attribute
  belonging to the XSL-FO namespace (the
  ‘http://www.w3.org/1999/XSL/Format’ URI). The XML Namespaces
  recommendation defines syntactic rules only.

>From a semantic point of view, the meaning of an attribute depends on
the element on which it is declared. I can do weird things like:
• accepting the xlink:href attribute on my extension element and give it
  a meaning that is different to what is defined in the XLink
  recommendation;
• or the other way around, defining a font-family attribute in the
  XSL-FO namespace and give it the same meaning as the no-namespace
  font-family attribute defined by the XSL-FO recommendation.

AFAIU, declaring attributes in the XSL-FO namespace is unacceptable not
because it violates the XML Namespaces recommendation, or the XSL-FO
recommendation, but the implicit convention that only the authority that
creates the namespace has the right to decide what belongs to it or not.
Nothing prevents me from defining my own schema in my own corner that
declares attributes in the XSL-FO namespace. Problems will appear only
when I start making that schema public.

Therefore:
• modifying FOP to accept prefixed XSL-FO attributes would correspond to
  implementing an extension of the XSL-FO standard. FO elements would
  accept a new set of attributes whose semantics would match the
  no-namespace attributes defined in the XSL-FO recommendation. Doing so
  would be unacceptable because we would hijack the XSL-FO namespace.
  Which we are not qualified to do that. It would be perfectly
  acceptable, however, to put all those attributes in the
  ‘http://xmlgraphics.apache.org/fop/extensions’ namespace, which would
  of course be totally useless.
• designers of extensions may declare attributes whose local names match
  the attributes defined in XSL-FO, and specify in the documentation
  that they are borrowing their semantics from XSL-FO. They may decide
  to put them in no namespace (i.e., the ‘per-element namespace’) or in
  a special custom namespace that cannot be the XSL-FO namespace (like
  ODF did). They may as well assign them totally different meanings.

So that effectively invalidates my patch. It wasn’t working anyway, as
it wasn’t taking into account the possibility that both font-family and
fo:font-family would be used on an element. Since from a syntactic point
of view they are two different attributes they wouldn’t be rejected by
the XML parser. I hadn’t thought of that.


>> 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,

Yes.


>    and, further, you must not put it in the XSL-FO namespace;

The sentence doesn’t say anything about that. That is enforced (IIC) by
the general convention that one cannot mess around with the namespace
defined by someone else. The effect is of course the same.


<snip/>
>>
>> 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?

Well, I suspect that what the sentence Simon quoted means, is different
to what it says. Let me put it here again for convenience:
  “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.”
All of the attributes defined by the recommendation (except xml:lang)
are in no namespace, i.e. not from the XSL namespace. So the
recommendation contradicts itself, unless you assume that the attributes
it defines are in the XSL(-FO) namespace.

Anyway, what I think that sentence actually means is what you wrote
above, which is that extension attributes must be in their own non-null
namespace.

<snip/>

Vincent

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


Mime
View raw message