[Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

[Fred Drake]

On 12/30/05, Jeff Shell <eucci.group at gmail.com> wrote:
> - the TAL namespace had a limited and proper list of attributes. A
> very limited set of names that could be (theoretically) validated with
> standard XML tools.

This should probably remain a goal, but I don't think it's as big a
deal as the ordering problem.

> - XML processing, if I recall correctly, does not cover ordering of
> tag attributes, nor gives them any significance. You couldn't have
> 'attr:title' have any dependency on 'attr:href', for example.

That's correct; attributes do not have order in the XML information set.

> As a result, there are a limited list of TAL keywords with a well
> defined order of execution.
>
> How would these namespaces impact that? When doing "proper" XML
> processing with TAL, would the 'attr' and 'defines' and other
> namespaces all need to be explicitly loaded?

We could easily say that each of these namespaces is processed at a
certain point in the evaluation order; that's easy.  Defining the
order of processing within any one of these namespaces could be done
on a strictly arbitrary basis ("sorted by attribute name", for
example), but remains arbitrary.  This would lead to unsavory
practices, like naming defines to control the order of evaluation
rather than to express what's stored in them.

I can't speak for others, but order of evaluation is often important
when I have more than one define on a single element.

The only example namespace I can think of that behaves this way is the
xmlns: namespace, and that's also special in that the prefix is
frozen.  It's dealing with a chicken-and-egg problem, which we don't
need to do.

> More namespaces increases the chance of namespace
> collision.

I'm not sure what this means; use whatever prefixes you want.

All this said, I understand Alex's desire to avoid long piles of stuff
in attribute values; it's not very common to have several lines of
stuff in an attribute.  In most situations where substantial text is
needed in an attribute, the attribute value is a reference (often via
URL) to some other resource.  But for what we're doing in TAL, that
doesn't make much sense: the template becomes harder to understand and
maintain, and the volumn of text is unlikely to be more than a handful
of lines.

I'm glad he's thinking about how we can improve the situation.


  -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
"There is no wealth but life." --John Ruskin