attribute vs. node
-
Here's a snipet from an MSDN example: doc.LoadXml("" + "Pride And Prejudice" + "19.95" + ""); Now, why is ISBN an attribute, not a node, vs. title and price? I've done a brief search to try and explain when something should be an attribute and when something should be a node, and I can't find a good explanation. It seems that price and title are attributes of a book too. Comments? PS - I'd like to thank all for answering my previous questions too! It is definitely helpful. Marc
You get a lot of personal opinions here. Many say you should never use attributes. I do not agree with that but thought must be used in your placement. Our local guidance usually says for unique machine identifiable info we use attributibutes. For one even though you can have a schema that says you have only one child node of a given name this can be overridden. For an attribute you can only have one. Now for your question: There is only one ISBN for a book (now I ask is that really true?) For the Title and Price you may want to have the title shown in many languages so you add all that you need and add a language attribute to the title block. Same for price, currencies, specials deal's etc. But they all point to the same book. Now for the ISBN question. If a book is then printed in a new language does it get a new ISBN? I do not know but if so they may have restricted them selves by this format. However if you are tracking each book the above hold true and is probably their logic. "I will find a new sig someday."
-
You get a lot of personal opinions here. Many say you should never use attributes. I do not agree with that but thought must be used in your placement. Our local guidance usually says for unique machine identifiable info we use attributibutes. For one even though you can have a schema that says you have only one child node of a given name this can be overridden. For an attribute you can only have one. Now for your question: There is only one ISBN for a book (now I ask is that really true?) For the Title and Price you may want to have the title shown in many languages so you add all that you need and add a language attribute to the title block. Same for price, currencies, specials deal's etc. But they all point to the same book. Now for the ISBN question. If a book is then printed in a new language does it get a new ISBN? I do not know but if so they may have restricted them selves by this format. However if you are tracking each book the above hold true and is probably their logic. "I will find a new sig someday."
Michael A. Barnhart wrote: machine identifiable I should have stated info not shown to the standard user. "I will find a new sig someday."
-
You get a lot of personal opinions here. Many say you should never use attributes. I do not agree with that but thought must be used in your placement. Our local guidance usually says for unique machine identifiable info we use attributibutes. For one even though you can have a schema that says you have only one child node of a given name this can be overridden. For an attribute you can only have one. Now for your question: There is only one ISBN for a book (now I ask is that really true?) For the Title and Price you may want to have the title shown in many languages so you add all that you need and add a language attribute to the title block. Same for price, currencies, specials deal's etc. But they all point to the same book. Now for the ISBN question. If a book is then printed in a new language does it get a new ISBN? I do not know but if so they may have restricted them selves by this format. However if you are tracking each book the above hold true and is probably their logic. "I will find a new sig someday."
Ah. So the "typical" usage of an attribute is to qualify the node, for example, the language attribute qualifies the book title and the currency attribute qualifies the price. That makes sense, but it seems that there are lots of exceptions, which I guess is why you get a lot of personal opinions. Well, I like how you put it. It provides some good guidelines as to when to use an attribute or not. It would seem then that David Stone's comment: You have elements(controls), attributes(properties), and it's all hierarchical(parent controls) would therefore be an inappropriate use of attributes. Properties of a control should be sub-nodes? What about the concept that something could be an attribute if it is the lowest divisible piece of information? In David's example, something like width could then be an attribute (of course, what kind of width--pixels, dialog units, inches, etc)? Oh boy. Marc Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka -
Here's a snipet from an MSDN example: doc.LoadXml("" + "Pride And Prejudice" + "19.95" + ""); Now, why is ISBN an attribute, not a node, vs. title and price? I've done a brief search to try and explain when something should be an attribute and when something should be a node, and I can't find a good explanation. It seems that price and title are attributes of a book too. Comments? PS - I'd like to thank all for answering my previous questions too! It is definitely helpful. Marc
ISBN is a property of the book, and there is a single instance, so it can be an attribute, or an element. For properties or children that have more than one occurence, relying on elements is necessary. (To be honest, not really too, one could concatenate all element content within a single line, adding a separator in much the same way than CSV files). All in all, you can think of attributes as a facultative tool to preserve size. The use of Xml elements increase the overall size of Xml streams, even when they have no children, and that's because of the markers : <, >, /. After all, everything in Xml could be made available as elements, and only elements. The trouble is those people from the W3C have messed the thing up about Xml by introducing attributes, headers like ?xml, doctype, ... which are not written using the Xml syntax, and of course that stinking DTD format, which is not expressed in Xml either.
-
ISBN is a property of the book, and there is a single instance, so it can be an attribute, or an element. For properties or children that have more than one occurence, relying on elements is necessary. (To be honest, not really too, one could concatenate all element content within a single line, adding a separator in much the same way than CSV files). All in all, you can think of attributes as a facultative tool to preserve size. The use of Xml elements increase the overall size of Xml streams, even when they have no children, and that's because of the markers : <, >, /. After all, everything in Xml could be made available as elements, and only elements. The trouble is those people from the W3C have messed the thing up about Xml by introducing attributes, headers like ?xml, doctype, ... which are not written using the Xml syntax, and of course that stinking DTD format, which is not expressed in Xml either.
.S.Rod. wrote: and of course that stinking DTD format Long live XSD:-D "I will find a new sig someday."
-
Here's a snipet from an MSDN example: doc.LoadXml("" + "Pride And Prejudice" + "19.95" + ""); Now, why is ISBN an attribute, not a node, vs. title and price? I've done a brief search to try and explain when something should be an attribute and when something should be a node, and I can't find a good explanation. It seems that price and title are attributes of a book too. Comments? PS - I'd like to thank all for answering my previous questions too! It is definitely helpful. Marc
The way I do it is, if something is a container, then it has subnodes. For example, if you're describing a menu in XML:
A
is a container for other things (items). A itself is just a thing, but it has various properties (type, text for the menu, and what app to run). Since those properties are simple values, they go as attributes. In your sample, there is no reason to have title and price as nodes IMHO.
-
Here's a snipet from an MSDN example: doc.LoadXml("" + "Pride And Prejudice" + "19.95" + ""); Now, why is ISBN an attribute, not a node, vs. title and price? I've done a brief search to try and explain when something should be an attribute and when something should be a node, and I can't find a good explanation. It seems that price and title are attributes of a book too. Comments? PS - I'd like to thank all for answering my previous questions too! It is definitely helpful. Marc
I think it really is a judgement call most of the time. My call is that core information which is always there and unique to that node should be an attribute. So ISBN is in, author and title are out. Christian No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002 -
The way I do it is, if something is a container, then it has subnodes. For example, if you're describing a menu in XML:
A
is a container for other things (items). A itself is just a thing, but it has various properties (type, text for the menu, and what app to run). Since those properties are simple values, they go as attributes. In your sample, there is no reason to have title and price as nodes IMHO.
Michael, In your example what happens when I have multiple languages. IMO "Title" should should be an element. You do not know how weird it feels suggesting this. Generally I am surrounded by those taught never to use attributes for anything, so I fight for them as proper usage.:-D "I will find a new sig someday."
-
I think it really is a judgement call most of the time. My call is that core information which is always there and unique to that node should be an attribute. So ISBN is in, author and title are out. Christian No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002Christian Graus wrote: core information which is always there and unique to that node should be an attribute. So ISBN is in, author and title are out. <joke>you can't have written a book. If you had, you would take a lot more serious the association of a book and the author.</joke> :laugh:
-
Michael, In your example what happens when I have multiple languages. IMO "Title" should should be an element. You do not know how weird it feels suggesting this. Generally I am surrounded by those taught never to use attributes for anything, so I fight for them as proper usage.:-D "I will find a new sig someday."
Michael A. Barnhart wrote: what happens when I have multiple languages Then suddenly you have a container of titles. :) <titles> <title language='US English'>The Color of Money</title> <title language='UK English'>The Colour of Money</title> </titles> Michael A. Barnhart wrote: I am surrounded by those taught never to use attributes for anything That's rather silly (just like most "NEVER DO xyz!" rules in programming) but whatever floats their boat, I guess. --Mike-- I'm bored... Episode I bored. 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm
-
Christian Graus wrote: core information which is always there and unique to that node should be an attribute. So ISBN is in, author and title are out. <joke>you can't have written a book. If you had, you would take a lot more serious the association of a book and the author.</joke> :laugh:
*grin* How apt - tags in a post on the XML board. I realise you were kidding, but just in case the joke was borne out of my lack of clarity, my point is that more than one book can have the same author, therefore it's not unique and so not an attribute. Christian No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002