* demerphq <demer...@gmail.com> [2007-09-27 14:50]: > Hear hear. From what ive seen the "attributes are evil use > tags" crowd usually justify their position by essentially > stating that they are crap schema designers who want to cover > up for their lack of foresightedness and planning and design > skills by ensuring that they will have every opportunity in the > future to correct things. Which is like a building designer > putting all the wiring on the outside of the walls because just > maybe sometime in the future somebody will want to put a socket > somewhere unanticipated. Well, fucking do it right the first > time damnit. Thats what "design" is for.
Yeah! And while you're at it, your methods should be "static final" by default, you lazy slob! God, the clueless idiots who leave all their methods overridable. No design skills whatsoever. And let's not even talk about those "dynamic" language proponents. Can't make up their minds about the types of their variables, the nimrods. * demerphq <demer...@gmail.com> [2007-09-27 23:30]: > On 9/27/07, Adam Atlas <a...@atlas.st> wrote: > > I think a decent rule of thumb is that attributes are for > > parameters that are not displayed to the user directly, while > > sub-elements are for structuring content that is displayed. > > Attributes can affect the display, of course, but their raw > > content should (usually) not be. > > I think that the rule of thumb expressed earlier by tgies is a > better one. When a piece of data is an inherent property of a > tag, which cannot have children, then it should be an > attribute. When it can have children of its own then it should > be a tag. The correct rule of thumb is narrower and more precise. XML is MARKUP. That means the document text should be TEXT. Everything that is *not* the document text should NOT BE IN the document text. That's it. If you are designing an XML vocabulary that needs to wrap bits of document in bits of metadata, then for the metadata, there is another narrow, precise, simple rule: if it's an atomic value, and you know there will only be one of them, then an attribute is the right place. URIs belong in attributes, f.ex. Datetimes are a good candidate. Stuff like that. Note that "you know there can only be exactly one of that" doesn't mean "you can't anticipate there ever being a need for more than one", it means "there cannot be more than one *by definition*". The `href` attribute in HTML links is a good example of attributes used correctly, on both counts. And if you are designing an XML vocabulary that consists only of metadata, then please take a cold shower right now and when you come back, go look for a better tool for the job than XML. > I don't buy the "its all the same" argument. Its not. Tags are > containers which can contain other containers, attributes are > inherent properties of the tag to which they belong. Yeah. `<a href>` (again) is a great refutation of the "attributes are superfluous" fallacy. > Anyway, XML is hateful, full stop. We are just quibbling over > the exact extent and nature of the hate. :-) It's the worst solution, except for all the others. Don't forget that SGML and XML are rooted in the document/markup world, and that's what they are for. They are not universal data structure serialisation languages, they are not glorified CSV, they are not generic grammars for each and every syntax with nestable blocks, they are not a hammer in a world of nails. People who insist on making every task a nail for which to use the XML hammer suck, but so do most people who rant about XML. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
