[Zope3-dev] Re: i18n domains vs. unique message ids -OR- why Shakespearean English was better

[Martijn Faassen]

Stephan Richter wrote:
[procedural matters]

I think the way you went about this and the way you presented your
changes could've been done in a better way. There were alternative
proposals and an active discussion which basically you dismissed
out of hand. You write the code, but it does make me feel disinclined
to give input.

> However, this is besides the point. It might be as well that you get enough 
> momentum and the proposal is accepted, but this is still only the first step. 
> Someone has to implement it. Jim spent almost two weeks on the recent ZCML 
> rewrite, so who would be willing to spend two weeks implementing this 
> proposal?

Willing sure, but my time is on a budget. I'd like to talk to Shane
about some of the details to see whether we can come up with something.

> > ZCML is an XML format. We should at least make some attempt to be
> > XML-ish here. The current implementation of the message id is in effect a
> > hack if you look at matters from an XML semantics point of view. Semantics
> > are introduced which are very hard to capture in an XML schema. I hope
> > we can at least agree in principle that the current implementation is a
> > hack and that we should look for ways to improve the situation.
> 
> I do not like the current solution that much that I would defend it to the 
> end, but it saves a lot of verbosity, which is great. Bloated ZCML would be a 
> pain to work with.

A few points, not constrained to the i18n discussion in particular:

  * considering semantics can help reduce bloat and increase learnability,
    readability and writeability.

  * more verbosity does not equate to bloat. More verbosity can on occasion
    be clarifying.

  * XML is indeed inherently a lot of typing. On the longer term it may be 
    useful to invent a non-XML shortcut syntax that can be translated back
    to XML. This is a cleaner solution than trying to twist the XML framework
    into something that is quicker to type.

> Personally I do not think that XML was chosen for configuration to use XML
> and all its semantics, but because it looks familiar to people and we were
> able to limit the functionality.

XML does not impose semantics, so I'm not sure what you mean with
XML and all its semantics. It does impose a certain structure. A structured
representation helps one consider semantics. It is also true that writing 
something in an XML-ish way will make it easier to use other tools built on 
top of XML, such as XPath and XSLT, as well as schema technologies for
verification and specification.

Quite apart from the whole XML issue, ZCML is a (domain specific) language,
and semantics are important in language design. Shane in 
particular has been making such semantic considerations and I consider
that to be a very good thing for ZCML.

> A Python version would have been too powerful and 
> intrigued us to do too much during configuration. 
> (Disclaimer: This is solely my personal opinion.)

A Python version would've increased the danger that Python application
code gets mixed with Python configuration code. Since component 
configuration should really be separate from Python, a separate domain
specific language is useful to encourage this. It helps us think about
configuration too, as it's right there in front of our noses. Another reason
is that the person configuring components is not always the same person as the
one that writes the components. It is helpful having a standard way
to do configuration in the form of a separate language instead of a myriad of
slightly or even radically different ways in Python code as you'd see
in Zope 2.

Regards,

Martijn