Hi Cliff.

I'm comfortable with both s-expressions and XML, but it comes down to the fact that I prefer to template in something that looks like the final product. I've been writing HTML for over 10 years. I know exactly what I'm building and when someone else who also knows HTML looks at the pages, they know what I'm doing. I am the group's designer, so that's not an issue.

I do understand the implications of Breve, I've done s-expression template generation in Scheme. I also recommended Breve to a friend who has a XML->C#/Java code generation engine as a better way to generate the XML than hand authoring. In the case of code generation, there's no reason to write stuff in XML, you get no benefit of experience and can gain big code-reduction wins using s-expressions both in abstraction and syntax cleanliness.

I'm not a hardcore XML geek, but I'm probably one of the more XML-friendly Pythonistas. I've done a fair amount of XML processing in the past, including a content system using XSL-T (mess of a language) that was XML Schema (mess of a language) validated. I ultimately decided, like most of the Python community, that XML was a last-choice option. The upshot was that I learned xpath and got Vim set up as a passable XML editor (though no schema support).

The nice thing about Kid and Genshi is that the Python (real python!) bits provide me with enough flexibility to take a set of data that wasn't built specifically for the page (e.g. something I'm reusing elsewhere) and transform it into the output I want. This is important because it lets me keep the data manipulation code close to the formatting code and keeps my business logic clean from formatting cruft. Separation of concerns.

I could do that using a text-based engine, but I know enough about XML to know that you shouldn't hand-generate XML and the fact that Genshi and Kid work at the XML Infoset level provides a strong guarantee that the page will come out well-formed. Genshi has the second advantage in that I'm able to leverage my knowledge of xpath to compose pages (or parts of pages) without the included pages knowing anything about it. Basically Genshi is what XSL-T should have been but isn't. It's a superb tool for transforming XML and I'd use it for that even if it didn't output HTML.

While I do value brevity for ease in input/editing/reading, I have an extensive (as in couple thousand lines of code) set of vim macros for authoring XML, web pages, and Genshi/Kid templates, so it's . I can generate the XML equivalent of a Breve template in about the same number of keystrokes and considerably fewer when the language is HTML and I can leverage my macro expansions.

I'm excited about Breve but not for web page authoring in TG. If I didn't have as much time/knowledge invested in the XML family, I'd definitely consider it strongly.

Familiarity (for most) stops the minute you introduce the engine's XML namespace.

Familiarity is entirely dependent on context. When you're working with web developers, HTML is more familiar than s-expressions. For programmers, they're not as big of a deal. In either case, I'd catch more flak for using an s-expression template engine to produce HTML than I do for an xml-attribute based one.

XPath

XPath is just a way of matching nodes, it does basically the same thing that selectors do in CSS. In an XML processor, it's the main tool for selecting and filtering XML. See the HTML cleanup example on Genshi for a sample use. The key in that example is that the 'bad' HTML doesn't know anything about the template. This isn't key for normal TG usage, but it can be handy. It is important for an XML processing chain.

XInclude

This isn't a really complex standard, it's mostly there to ensure all the XML tool vendors do things in a portable way.

XML namespaces

This is a mess even though it's not that difficult conceptually. The XML authors wanted to make sure that tools processing XML (e.g. genshi) didn't accidentally process stuff not meant for it (e.g. kid's py:for rather than it's own). They did this by name mangling.

All you need to understand about namespaces is that they work like C preprocessor directives that only work on element/attribute names. The #define equivalent is xmlns:XXX="url" where XXX is the prefix (e.g. py: in the case of genshi/kid) and url is a unique URL (which is different between kid and genshi, and is what makes them different 'languages'). An xml prarser basically does macro expansion to turn XXX:foo (called the qualified name or qname) into {url}foo (the full name). All subsequent processing then works on the fully expanded name. One wrinkle: if a default namespace (xmlns="defaulturl", note lack of :XXX) is defined, all elements without a prefix (bar) are expanded using that url ({defaulturl}bar). If there's no default namespace, no expansion occurs.

The problem is that people author docs/XPath expressions/whatever thinking of the qname as the full name and processing tools need to know how the prefixes map to the URLs, which trips people up. It only really becomes messy when you're trying to do the XML-processing-XML mess that is XSL-T. I'll leave it at that.

I don't feel [XML is] designed to be hand-written

XML was designed to be a document language in the SGML tradition. It's also used as a data-interchange language. Both were pretty much anticipated and intended by the working group. It was also intended that documents authored in XML would be done with tool support. My comment on not hand-generating XML is more about not screwing up the escaping and formedness rules than it is about actually authoring.

Breve support[ing] XML schema and namespaces

Don't support XML Schema. Seriously. There's a difference between a schema and XML Schema. That said, there's no real need to support any sort of schema validation directly in Breve. People who care about schema validation will want to validate the output and can do that without support from Breve.

For namespace support would be convenient for general XML use, but it actually isn't needed on my friend's project since he doesn't use namespaces. There's debate right now in the XML community as to whether namespaces are worth the effort or not and if you're not a worldwide standard, many XML toolchains make namespaced XML more trouble than it's worth.

A noble goal, just do it in Schematron or RELAX-NG if you do it. I keep meaning to implement something like Joe Clark's nXML in Vim using Python and tying it in to the Vim7 omnicomplete system. The problem is that I don't do enough varied XML processing to make this worthwhile to myself, so it'd be more of a cool thing/benefit to mankind sort of thing and I've got a serious list of 6 of those right now (JS linker and TurboGears admin being the other two applicable to webdev).

XML, for better or for worse, is the standard for application-neutral data storage and I don't see that changing in the future. JSON will probably wind up as a more common wire format unless the Efficient XML gents pull through (Efficient XML is a very cool initiative if you have a spare hour to read up on it).

Happily, we're finally getting to the point where developers are creating solutions to real problems instead of academicians and bigcorps solving theoretical ones. The rise of Relax-NG and of ElementTree and Kid/Genshi in the Python world is further evidence of this.

As for our discussion, you're neither the first nor will you be the last to point out that s-expressions are a more efficient expression of XML. People's taste in templating differs. I'm as derisive about text-templating for HTML generation as you are. I can understand the arguments, but my value systems are different. I'll definitely keep Breve in mind when I'm doing non-web projects. Catch you on the TG mailing list.

The big reason I prefer Genshi/TAL/Kid to other template languages is that my designer can produce valid XHTML that he can test in a web browser without installing any additional software. Once he's done with the mockup we can Just Add Attributes to the XHTML without removing his ability to make changes and test directly in the browser.

If I had to do everything myself, I might use something Stan-like... but fortunately I don't have to.

I don't use code generation for much the same reason I wouldn't use Python to express something that is naturally thought about as markup. Lots of data-related XML isn't best thought of as markup (and I do use XML generators for that, and not template languages). HTML isn't one of those. (Though I suppose one could argue that as the DOM becomes increasingly important, it becomes more important to remember the structure of the document in addition to its text.)

Incidentally Pylons uses the same API that TurboGears uses for templating languages, so you get the same choice of languages, presumably including stan and Breve. Probably CleverHarold too -- it's generally easy to figure out Buffet than any of the individual templating language APIs, even if you didn't care about language choice.

for most of us, its that we'd like our templates to be workable by people who are not python developers, therefore the mixture of code and regular HTML/XML markup. i dont think you'd find a web designer who wants to build pages as giant Python datastructures.

if you want to know why people pick one template system over another, looking at it as a question of one's own "enlightenment" vs. their status as the "unwashed masses" is one way to go...but probably a little more ego-balanced way to look at it is that its a question of the specific development/maintenance process (i.e. whos developing, whos maintaining, how many people, what's their skillset, how often do things change and how much, etc), personal taste, and performance tradeoffs. thats why all the frameworks these days have worked hard to allow template languages to be swapped out and even combined together...no one of them would ever fit the bill for all people and scenarios.

i would also say that comparing any of the current python offerings to PHP is like comparing any of ten or twelve different kinds of fine wine to Bud Light.

sure, whos to say that the world of HTML/CSS developers wouldnt want to write their templates as python data structures. but the burden of proof in this case is on the Stan/Breve camp to illustrate why more web designers arent using these methods, and why typical code-embedded HTML approaches like PHP and JSP are overwhelmingly popular.

my own experience does encompass working with probably a hundred sitebuilders over the course of many years who are almost unanimously terrified of writing/touching a single line of server-side code in any case, and have absolutely zero interest in trying to think in terms of datastructures, and im fairly certain would have the same zero level of interest in producing anything that does not look 95% like literal HTML as source code - this includes people who write JSP pages for a living (and not for cheap, either) yet have not the slightest idea what a Java class is. this is why the JSTL is so popular in JSP pages...the original JSP still didnt look enough like markup for people.

its also the reason I think code-embedded HTML works out just fine in practice - HTML designers are very respectful of what the developers do and in practice never break anything that's been put in place.

I think the last set of comments nail the issue, is not what is better is more a thing of specialization, in our work it's more then common to have some people work on the interface and some work on "the backend" in those cases the most common thing (which is what TG should aim at) is that the person working on the frontend is a) not a python developer, b) not a fulltime worker on whatever the backend guy is doing, (keep in mind most small companies outsource their CSS design, either by pay, favor or screenscrapping :p) and c) people don't like to learn yet-another-tool.

Now leaving the disadvantages of generating html "from the controller" in TGspeak, python templates reinvent the good part of php which as you said is a good thing since for a new app I'll prefer to use a php-like template engine instead of the WSGI/php proxy, although in some cases it may be a necesary evil.

last but not least I don't think comparing to php is a good thing because I believe we all have suffer there, and this should be seen as a good thing because they are reimplementing the stuff that "they got right", now ones a template engine starts doing db queries or calling methods on the core of the app (leaving out the AJAX thing because that is a "controlled environment") then I totally agree with you that they are reinventing php. which by the way is something you didn't mention the directive that kid has and genshi will implement by preasure (I believe) that is something that if used in the wrong way could bring havoc and destruction so common on the php grounds.