Examples using XML elements for content attributes
Consensus seems to be that no one really likes this idea.
See content, ElementsVsAttributes.
<content> <type>text/plain</type> <language>en</language> <language>fr</language> <value> Then the maestro pulled a rabbit out of hat, saying voila. He had a certain je ne sais quois, how you say? I don't know what? </value> </content>
Comments
[AsbjornUlsberg, RefactorOk] Though it makes the exact same sence on a conceptual level as attributes, I dislike using elements for everything. When Echo is serialized in XML (which will be the main serialized language we'll see it in -- maybe even the only language) we shouldn't allow alternative syntaxes. If Echo should be "allowed" serialized in other languages, like e.g. Enamel (where there aren't any attributes), alternative syntax should of course exist, as long as the object model stays the same.
-
[StefanRam] When the problem is the lack of structured attributes, it does not seem to help to remove attributes altogether. I.e., There are binary relations (properties), like "language( text, en )" and unary predicates, like "isPlaintext( text )". One would like to use the syntax of attributes for the properties (binary relations) and types for unary predicates (for the is-a relationship), because this seems to be the most natural way; but in XML this is not possible, because attributes can not be repeated and do not allow structured values. Therefore, in XML, one is forced to abuse direct sub-elements to notate properties. So, I said, "let's allow structured and multiple attributes and types!", which lead me to a notation that I call "Unotal". The above example, in Unotal, looks as follows.
< &[text/plain] language=en language=fr [Then the maestro pulled a rabbit out of hat, saying voila. ] ~ [He had a certain je ne sais quois, how you say? I don't know what?]>
(Some abbreviation to allow multivalues, like "language={en fr}" or so, is planned. The "~" is a concatenation operator. A multi-line string might be used instead, when the application will interpret the line-break as whitespace.)
[KenMacLeod] The presentation of the alternate syntax isn't to suggest that multiple syntaxes are to be used, but just that that design decision hasn't been entirely nailed down yet. See "Attributes vs. Elements" in EchoExample.
[AsbjornUlsberg] Oh, so it was only to show how ugly it is? Well, then it's ok.
[KenMacLeod] I kinda like element-only in many cases In this case, though, note that it's the only way to allow two languages to be applied. One can't do that with xml:lang.
[AsbjornUlsberg] If you like element-only, you probably like Enamel too. It's neat. But when dealing with XML, which has attributes, I think they should be used. Also, the multiple language-issue isn't much of an issue, is it? It's true what you write, but I don't think we need to offer ways to solve this "problem" in Echo. At least not in v1.0.
-
[MaciejCeglowski, RefactorOk] There are many weblogs and posts that are written in multiple languages. We shouldn't let syntax preferences get in the way of dealing with what is actually out there. Enforcing "one language per post" goes against actual observed usage in the blogosphere, where non-English bloggers in particular will often mix English and their native language in a post. There are two ways around this. The 'hack' way is to use the 'MUL' language attribute, for multiple languages. The better way is to let users specify 1+ languages, however that fits in the syntax. Why not bite the bullet and get language working right in version 1.0?
-
[LachlanCannon, RefactorOk] Isn't that an issue for the entry authors? If it's being serialised in xhtml, then when swapping languages inline, they can use lang / xml:lang themselves. eg <p xml:lang="en">Balloons, clowns <span xml:lang="la">et cetera</span> were in abundance.</p>
[AsbjornUlsberg] But is it really necessary to have different languages in each <content> element? Isn't it enough to differ the languages of each <content> element with "xml:lang"?