XML: Attributes vs. elements

Post #12,560 by admin 10/9/01 11:04:27 PM Reply	XML: Attributes vs. elements Any thoughts on when to use one vs. the other? eg: <object attr1="one" attr2="two /> vs. <object> <attr1>one</attr1> <attr2>two</attr2> </object> Regards, -scott anderson
Post #12,626 by neelk 10/10/01 11:36:51 AM Reply	Re: XML: Attributes vs. elements On mailing lists and newsgroups, an immense amount of bandwidth is wasted on when you should use attributes and when you should use elements. However, there's no real semantic difference between the two. This means that your choice really comes down to aesthetics and pragmatics. First, no matter how fancy your tools, to debug it a human being will have to grovel through formatted text, so write your DTD or schema so that the XML documents you generate read well to a human. Second, remember to keep your tools in mind: when you have a choice pick whichever of elements or attributes will make it easiest to write document-munging programs with whichever API -- DOM, SAX, XSL, regexps, whatever -- that you use. The goal is to minimize bugs, and to make it easy to debug the ones that get through. Keep your mind on that, and you won't go wrong. Abstract style rules will simply screw you up, because there is no underlying principle at work here, only pragmatics.
Post #12,635 by admin 10/10/01 12:21:21 PM Reply	Keeping tools in mind... Second, remember to keep your tools in mind: when you have a choice pick whichever of elements or attributes will make it easiest to write document-munging programs with whichever API -- DOM, SAX, XSL, regexps, whatever -- that you use. This is the sort of discussion I'm looking for. What are the advantages between the two methods when taking the tool into consideration? We're already using or are contemplating using most of these that you mentioned: SAX, DOM, and XSL. Regards, -scott anderson
Post #12,641 by ChrisR 10/10/01 12:39:04 PM Reply	One thought... ...is that one should anywhere and everywhere avoid putting strings which need to be escaped out within an attribute. Get's to be too much of a pain in that you are already within a quoted string. Along similar lines, don't put long text fields that might wrap into multiple lines in an attribute.
Post #12,643 by admin 10/10/01 12:45:10 PM Reply	Something else I noticed... Or at least, this is my supposition: I have a list of <SOMETAG attr="" attr="" /> tags, and the DOM parser is putting blank TEXT elements in between each SOMETAG element. I would guess that this doesn't happen with elements, but I haven't tested it. The point about escaping things is well-taken, though. Thanks. I've seen a number of places where attributes are used to modify the data in an element, such as: <TEMPERATURE units="Celsius">40.3</TEMPERATURE> Regards, -scott anderson
Post #12,662 by drewk 10/10/01 1:15:00 PM Reply	Attributes implies (to me) an inherent property As in your example, temperature must have units. It describes something about the nature of the object. Elements are an arbitrary number of items that happen to belong to the particular instance of the object. That's how I see it, anyway. We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link\|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html\|Thomas Friedman]
Post #12,687 by admin 10/10/01 2:43:11 PM Reply	Re: Attributes implies (to me) an inherent property <ATOM> <NAME>Somethinium, I don't have a periodic table in front of me</NAME> <ATOMICWEIGHT>23</ATOMICWEIGHT> <BOILINGPOINT units="Celcius">125</BOILINGPOINT> </ATOM> Which should be an attribute...? Regards, -scott anderson
Post #12,692 by Another Scott 10/10/01 3:08:37 PM Reply	Sodium. Glad to help. :-)
Post #12,753 by cforde 10/10/01 7:05:35 PM Reply	Attribute I think the name should be an attribute. The element values are particular to the thing that is named. The relationship in my mind is "if I were to put this into a table, which column(s) would comprise the primary key". Those become attributes to the tag. The rest become elements within it (data about the primary key). 3rd normal XML anyone? Have fun, Carl Forde
Post #12,868 by drewk 10/11/01 10:04:33 AM Reply	I'll agree with Carl here The idea that the XML analogue to a primary key would become an attribute and everything else is elements. Hmm, wait. I guess it sort of depends. Okay, here's what I really think. No, wait, that isn't it either. (Damn.) What I was thinking was that anything there can be only one of -- an atom can only have one atomic weight, one name -- is an attribute. Then the elements would be however many protons, neutrons and electrons. Each of those would have as elements their size, charge, etc., and would have as elements the number of quarks, gluons, yadda yadda. But that seems to sacrifice flexibility and usability for theoretical "correctness." So, umm, like I said ... it depends. HTH. We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link\|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html\|Thomas Friedman]
Post #14,400 by deSitter 10/21/01 4:05:32 AM Reply	Implies to Me - Design Idiocy OOP is (or should be) about objects and messages, and message passing semantics - not about all this ridiculous falderal. It reminds me more of philosophy than programming. "Is it a thing in itself? Does it have innate thingiosity? Is it transcendant or immanent?" Are those keywords yet?
Post #14,424 by admin 10/21/01 9:57:49 AM Reply	Once again, don't pontificate... ... where you have little clue. Objects have attributes (yes, even in Smalltalk). They can also have contained objects (elements). Neither of these things has anything to do with message passing. If you want message passing only, without attributes, then go use a functional programming language. Regards, -scott anderson
Post #12,751 by dpeterson 10/10/01 7:02:51 PM Reply	Prefer elements over attributes In my experience, I find that elements are preferable over attributes. As an XML document/schema evolves over time, it is easier to turn a simple XML element into a complex/compound element as compared to turning an attribute into a compund/complex element. Attributes are most useful for indexing when you want to normalize the "objects" in the XML document. Darryl A. Peterson I'm not as funny as I think I am.
Post #12,754 by admin 10/10/01 7:11:16 PM Reply	OK, so starting to form a distinction here... Attributes as indexing (as cforde pointed out as well). Regards, -scott anderson
Post #12,870 by drewk 10/11/01 10:07:41 AM Reply	Yeah, back to what he said again Attributes as indexing to indicate, to the parser and the human reader, which object you're referring to. You can define in the DTD that each <atom> can only have one <name> element, can't you? We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link\|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html\|Thomas Friedman]
Post #12,932 by tuberculosis 10/11/01 2:20:48 PM 8/21/07 5:56:12 AM Reply	My rule of thumb Which I got from someone or other and seems to make sense: Elements == Data Attributes == MetaData <User id="1"> <FirstName>Todd</FirstName> <LastName>Blanchard</LastName> </User> where id is a generated key sort of thing which can be used in relationships later on.
Post #12,981 by admin 10/11/01 4:26:47 PM Reply	Ah, nicely succinct. Thanks. Regards, -scott anderson
Post #14,407 by deSitter 10/21/01 4:59:33 AM Reply	Snort That is so hokey. Not your description, just the situation.

Welcome to IWETHEY!