A question of XML proportions

[PEN]

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.

[LoneRobot]

ok, ta paul.

[drdubosc]

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.

[LoneRobot]

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 tomaydo, i say tomarto thang??

[PEN]

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?

[drdubosc]

... i think it must be largely a, you say tomaydo, i say tomarto 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.

[PEN]

So you are saying there is a bigger reason to use the innerText then? It is common practice?

[LoneRobot]

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

[ZeBoxx2]

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>

'<td></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 [code] tag messing up formatting

[MarcoBrunetta]

Also, AFAIK, it's also good practice to not use "inner text" on nodes that have child nodes. You'll notice the XML file will have kind of strage formatting if you do this, even though it can be done.

[LoneRobot]

great, thanks rich - this thread has been really useful. I was thinking that depending on the data type would depend on whether things were nested or not - ie a stored morpher has channel,keytime,in/out interp type etc so could be nested and a stored TM could just be placed into the node on it's own, perhaps as an attribute of the xml node.

[drdubosc]

.... way 1 is right, and way 2 is wrong, IMO....

Yup, ZB, LR, PEN, that's too strongly put ... I'm being a purist :).

[LoneRobot]

nothing wrong with that! thanks for your input, as always Dr.

[erilaz]

If anything, I prefer the innertext method purely for readability, even if it does make the file larger. I've not done a huge amount of XML parsing myself, but for eye-scanning I find the attribution method frustrating.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.