One thought...

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

Welcome to IWETHEY!