[ZPT] RE:Re: [Zope] prevent quoting in tal:attributes

[fergal at pop.esatclear.ie]

I'm not suggesting support for SGML, there is plenty of doc processing going on with XML and it's perfectly legitimate to read in an XML doc with unexpanded entities and expect to be able to throw it out again with unexpanded entities. Sometimes it's essential that those entities remain unexpanded, for things like external entities. Sometimes there is no XML expansion available, sometimes expanding the entities is just a really bad idea (like when the entities are &chapter1;, &chapter2; etc., it would be nice not to expand them inline). Possibly these users shouldn't be using TAL, I don't know.

So there are some XML applications where this is absolutely required. Whether it's worth supporting them, I don't know. Given that they are part of the "one thing" supporting them comes under the "do it well" part of the UNIX philosophy. At the moment there is a hole in the set of well-formed, validating XML that TAL can produce. It's a relatively obscure hole but it's a hole nonetheless.

I don't really have an opinion about whether it's worth filling. I certainly have no current need for it. I'm just pointing out that it is purely an XML problem.

I'd suggest not using "structure" as the keyword either, it should be "allowentities" or something snappier than that but meaning the same thing and applicable to tal:replace, content and attributes.

The point about tal:replace="structure blah" is that it allows not just unescaped entities (in attributes and elsewhere) but also non-well-formed XML. What's proposed would also be optional and would at worst lead to well-formed but non-validating XML and so if conserably safer than structure,

F


Original Message:
-----------------
From: jamie at audible.transient.net
Date: Thu, 2 Oct 2003 03:33:44 -0700
To: zpt at zope.org
Subject: Re: Re: [ZPT] RE:Re: [Zope] prevent quoting in tal:attributes

fergal at esatclear.ie wrote:
> I agree that it is dangerous. Would you also argue that
> tal:replace="structure blah" should not be there either?

No, again, I speak only of attribute values.

> The example you gave demonstrates exactly what's wrong with it but
> if the string has been generated by the application and the author
> really wants to put an entity in the output then I'm not convinced
> we should stop them? Using TAL for document processing (as opposed
> to interactive web stuff) is a perfect example of where this is a
> genuine requirement and doesn't pose a security risk,

You can call it risk, or you can call it flat-out data corruption, or
you can call it perfectly acceptable behavior.  Whatever you call it,
is, as you've identified, dependant upon the application.  But now
consider that Page Templates only recognise two modes of application,
XML and HTML, and neither of these require the requested feature.
Sure, you *can* build other document formats with page templates, but
that doesn't mean you *should*, or that the *syntax* should be
extended to make it easy to fudge it.  I'll envoke (once again) a
tenet of the UNIX philosophy, "do one thing, and do it well."  I can
appreciate that Dieter's SGML application is tantalizingly close to
being realizable with stock Page Templates, but by compromising the
treatment of attribute values for one application you do it for all of
them.  Does it have to be that way?  Probably not.  The media type is
already a behavior modifier, I don't see any reason why one couldn't
add their own proprietary extension to the known media types then tie
new behaviors to it and to it alone.  (Don't construe this as my
suggestion of how to futher bloat the main code-base though, I think
the changes should be reverted and the entire thing dropped.)

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

_______________________________________________
ZPT mailing list
ZPT at zope.org
http://mail.zope.org/mailman/listinfo/zpt



--------------------------------------------------------------------
mail2web.com™ - Check your email from the web at http://mail2web.com.