[Closed] A question of XML proportions
Hello,
Are there any advantages to using the .innertext property of an XML node over the attribute? I’ve seen different ways of formatting these documents, and still wasnt sure what was the correct way (if there is an incorrect way inside the structuring format)
Since they both return strings you’d have to cast anyway so i was thinking it must be down to the slightly simpler syntax or something?
I’ll point out i’ve been using XML for a while now to store data but was interested if anyone noticed (or cared) about the difference?
I see the innerText property as some where that I dump large amount of data about something and properties for storing simpler values and parameters. I have never checked if one is faster to access then the other how ever. I’m guessing there would be little difference.
Hi, LR … can you give an example … do you mean an XML Attribute by “the attribute”?
If you do, the difference is semantic, on the XML side: values of nodes (sometimes accessible by .innertext) can be multiple elements or subtrees, but attributes can’t.
So a node’s attributes should be used to store only metadata, that aren’t part of the data itself, but intended to help interpret it (keys, types, etc.).
The data itself should stored in the value of a node, which leaves open the possibility of 1:n relationships, and extending or modifying the data structure at some later stage, without excessive faffing about.
Sorry in advance if I’ve got the wrong end of the stick, here.
hi dr,
thanks for your reply - you are spot on the money, it was something that i had largely thought sematic - I was refering to the attribute as an XML attribute.
This is how the two ways format in the xml document currently
innertext method
<lonerobot><data>waheey</data>
</lonerobot>
attribute method
<lonerobot><data thevalue=“waheey”/>
</lonerobot>
Im wondering if storing inside the node makes it clearer for things like recursion, as you can pass the xmlnodecollection, but again i think it must be largely a, you say [i]tomaydo,[/i] i say [i]tomarto[/i] thang??
Assuming <data>waheey</data> is real data, not information about data … (the trick is knowing one from t’other) … way 1 is right, and way 2 is wrong, IMO.
For a small self-contained script, tomaydo is just fine, if it saves trouble. But stick to tomarto if it doesn’t save much. It’ll be easier to code to, extend, and maintain, in the long run. All the tools expect it, as you suggest. Imagine, for example, tying your code into a relational db.
When ever I do something as simple as your example I use the second method just so I have a named parameter as I’m usually storing several. Have a look at my example script on my site for saving out a Max file (part if it only) to an XML file and I do it all with attributes and I don’t think that I use the innerText at all. I guess I could be saving the final bit of data in the innerText.
Have you looked at how they used it with XAF files?
So you are saying there is a bigger reason to use the innerText then? It is common practice?
Hi chaps, thanks for the replies. you’’re right Paul, XAF uses the attribute method. However I had read a couple of bits here and there (programming books i’ll add) saying it was better practice to use the inner text. Again, this is probably down to what dr mentioned – using with components that are expecting a certain syntax.
However, im sure no method is wrong if used within the routine that is expecting a certain structure, especially in a context of storing custom information. I guess the trick is to have routines that can be used again and again for any type of data
The way I think of it is the same as drdubosc’s; one -is- the data (what the data represents, and the actual data value), and the other -describes- the data. E.g. if you take an HTML table TD element (deprecated bits here as you would use CSS for them):
<td align="right" valign="top">myData</td>
‘
’ tell the browser that it is dealing with a table cell.
‘myData’ is the actual data in that cell.
‘align’ and ‘valign’ only describe something about that data; in this case, how it should be aligned within a cell.
That said, unless you’re making actual industry-hardened XML documents, providing a validating schema and everything, ‘XML’ is pretty much a free-for-all with the only limitation being what drdubosc mentioned… attributes are uniquely named for an element, so you can only have 1, whereas inner elements can be many.
So…
<material type="Standard" name="myMat" twosided="true" diffusecolor="1.0,0.50,0.25" />
Is every bit as ‘valid’ as…
<material>
<type>Standard</type>
<name>myMat</name>
<twosided>true</twosided>
<diffusecolor>1.0,0.5,0.25</diffusecolor>
</material>
Even the most naive XML parsers will have no trouble dealing with either of them*, and just upon seeing the above example, it’s easily understandable why somebody would choose to go with the first option – regardless of how it breaks the data vs metadata model.
- I don’t think either could be called proper ‘XML’, they just have an XML-like structure, which is why it’s still a ‘good’ format to use, as you don’t have write your own parsing routines for whatever crazy format you might come up with yourself ( been there, done that, disastrous results )
Edit: missing / in
tag messing up formatting